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ABSTRACT 


Project  SUE  is  designin 
sharing  operating  system 
computers.  This  report  is 
general  structure  and  of  th 
varying  detail.  Functional 
Kernel  and  the  system  pr 
System  is  outlined.  Gene 
presented  for  the  Basic  Fil 
description  is  given  of  the 
project  to  facilitate  the  wr 


g  and  building  an  extensible  time- 
for  the  IBM  System/360  series  of 
a  preliminary  description  of  its 
e  design  of  particular  components  in 
specifications  are  given  for  the 
imitives.  The  structure  of  the  I/O 
ral  functional  specifications  are 
e  System  and  the  Banker.  A  detailed 
System  Language  developed  within  the 
iting  of  the  operating  system. 


PREFACE 


This  report  is  intended  to  represent  the  technical  status 
of  Project  SUE  in  January  1972.  It  is  composed  of  individual 
reports  on  various  areas  submitted  by  the  project  members. 
These  reports  have  been  extensively  edited  by  J.W.  Atwood  for 
consistency  in  both  content  and  style.  SUE  is  an  ongoing 
project,  and  substantial  progress  has  been  made  while  this 
report  was  being  prepared.  The  only  way  to  ensure  absolute 
currency  of  the  report  would  be  to  stop  the  project.  Rather 
than  doing  that,  we  have  decided  to  present  the  progress  made  by 
the  project  up  to  January  1972,  and  record  progress  made  after 
that  time  in  a  future  report. 

Project  SUE  has  received  financial  support  from  the 
Computer  Systems  Research  Group,  and  from  individual  grants  to 
project  members  from  the  National  Research  Council  of  Canada. 
The  Computer  Systems  Research  Group  is  an  interdisciplinary 
group  formed  to  conduct  research  and  development  relevant  to 
computer  systems  and  their  application.  It  is  jointly 
administered  by  the  Department  of  Electrical  Engineering  and  the 
Department  of  Computer  Science  of  the  University  of  Toronto,  and 
is  supported  in  part  by  the  National  Research  Council  of  Canada. 
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1.  INTRODUCTION 

Project  SUE  was  established  in  March  1971  [ Tsichritzis 
et  al.  1971]  to  design  and  build  an  extensible  time-sharing 
operating  system  for  the  IBM  System/360  series  of  computers. 
The  objective  is  to  combine  academic  research  with  the 
development  of  a  practical  system  which  will  be  flexible, 
efficient,  reliable,  and  (above  all)  understandable. 

The  most  widely  used  contemporary  operating  system  is 
undoubtedly  OS/360.  Its  massive  initial  cost,  large  size, 
substantial  inefficiencies,  and  residual  unreliability  all 
testify  to  the  need  for  an  improved  methodology  for  operating 
systems.  Many  researchers  have  contributed  to  our  theoretical 
and  practical  understandings  of  the  organization  and 
construction  of  operating  systems.  Several  (e.g.,  Dijkstra 
[1968],  Brinch  Hansen  [1970],  the  MULTICS  group  [ Corbato  and 
Vyssotsky  1965],  and  Lampson  [1969])  have  demonstrated  the 
utility  of  their  techniques  in  full-scale  systems,  but  on 
uncommon  machines  (X8,  RC4000,  GE645,  and  BCC-1) .  Users  of  IBM 
computers  have  thus  not  benefited  directly  from  their  work.  It 
is  this  consideration  which  prompted  us  to  attempt  to  implement 
many  of  their  ideas  on  the  System/360. 

We  have  neither  the  manpower  nor  the  desire  to  compete  with 
the  size  and  generality  of  OS/360.  Rather,  we  are  aiming  at  an 
effficient  system  which  provides  a  modest,  but  easily  expandable 
range  of  services.  The  initial  system  will  support  a  single 
interactive  facility  and  very  little  else.  However,  it  is  being 
designed  as  an  open-ended  system  with  the  intention  that  both 
other  language  processors  and  other  capabilities  (e.g.,  text 
editors,  file  systems,  batch  streams,  real-time  subsystems)  can 
be  easily  added  without  requiring  modifications  to  the  basic 
system.  We  have  chosen  to  design  and  build  a  completely  new 
system,  sacrificing  the  ability  to  incorporate  OS/360  components 
for  freedom  from  OS/360  conventions  and  idiosyncracies. 
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The  stringent  reliability  requirements  of  the  time-sharing 
environment  and  the  open-ended  nature  of  our  system  require  that 
it  be  extremely  self-protective  (a  major  failing  of  OS/360).  A 
design  criterion  is  that  neither  the  erroneous  nor  the  malicious 
program  shall  be  able  to  "crash"  any  other  user,  or  the  system, 
under  any  combination  of  circumstances. 

We  are  indebted  to  Randell  and  Dijkstra  for  the  twin 
observations  that  "Reliability  is  not  an  add-on  feature"  and 
"Program  testing  can  reveal  the  presence  of  bugs,  but  can  never 
assure  us  of  their  absence".  We  can  only  have  confidence  in  our 
system  to  the  degree  that  we  have  structured  its  design  to  make 
it  comprehensible  and  have  assured  ourselves  of  its  logical 
correctness.  We  have  four  principal  tools  for  this  structuring: 
cooperating  processes,  virtual  machines,  tightly  controlled 
interprocess  communication,  and  our  System  Language. 

Each  component  of  the  system  will  be  implemented  as  one  or 
more  processes.  Processes  are  logically  asynchronous,  except 
when  they  are  explicitly  synchronized  by  means  of  message¬ 
passing  primitives.  A  family  of  processes  is  said  to 
"cooperate",  if  it  is  guaranteed  that  each  request  for  service 
receives  the  appropriate  response  within  a  finite  time.  There 
are  a  variety  of  techniques  for  demonstrating  that  properly 
structured  families  will  cooperate  [Dijkstra  1968,  Habermann 
1967,  Holt  1971]. 

The  system  will  be  constructed  as  a  hierarchy  of  virtual 
machines  [Dijkstra  1968].  The  Kernel  will  allocate  the  CPU, 
handle  all  interrupts,  and  implement  message-passing  primitives. 
Above  this  level,  each  process  has  its  own  virtual  computer  with 
a  straightforward  communication  system.  Higher  levels  will 
provide  I/O  and  filing  systems,  which  may  be  used  to  implement 
levels  of  subsystems  to  any  desired  depth.  This  will  permit 
subsystems  with  very  different  resource  allocation  policies 
(e.g. ,  time-sharing  and  batch)  to  freely  co-exist,  and  will 
permit  new  systems  to  be  debugged  without  disturbing  running 
systems.  This  philosophy  will  allow  an  installation  to  tailor 
its  version  of  the  system  to  its  requirements  and  to  dynamically 
reconfigure  when  its  requirements  change.  It  also  greatly 


3 


reduces  the  problem  of  establishing  correctness,  by  factoring  it 
into  separate  "proofs”  for  each  level. 

Processes  will  be  allowed  to  interact  only  by  means  of 
tightly  controlled  communication  paths.  For  example,  processes 
may  exchange  messages  only  via  their  ports,  which  are  connected 
to  message  buffers  called  mailboxes.  The  ability  to  connect  a 
port  to  a  mailbox  is  carefully  regulated.  In  general,  no  two 
processes  will  access  the  same  data.  This  means  that  the 
interface  to  a  process  is  defined  quite  simply  as  the  behaviour 
of  its  ports.  In  addition,  this  provides  natural  firewalls  so 
that  a  disaster  may  be  kept  local  to  a  failing  process. 

Finally,  we  are  writing  the  entire  system  in  a  language  of 
our  own  devising  [Clark  and  Horning  1971].  We  do  not  feel  that 
it  would  be  manageable  any  other  way.  The  language  contains 
many  "high  level"  features  which  facilitate  writing  (and 
reading)  nicely  structured  programs,  yet  can  be  compiled  into 
efficient  System/360  code.  It  also  permits  very  "low  level" 
control  of  code  emission  and  memory  allocation,  where  these  are 
required. 

During  its  initial  period.  Project  SUE  has  largely 
concentrated  on  the  development  of  a  coherent,  flexible,  and 
well-documented  design.  No  major  obstacles  have  been  uncovered, 
and  large  portions  of  the  project  are  now  moving  from  design  to 
implementation. 

Internal  project  documentation  and  history  consists  of  a 
large  (520  page)  and  growing  Project  Workbook.  This  Status 
Report  is  a  summary  of  our  progress  up  to  approximately  January 
1,  1972.  The  design  of  our  operating  system  is  still  not 
complete;  as  evidence  of  this  fact,  the  reader  may  discern 
discrepancies  among  the  sections  of  this  report. 

We  feel  that  there  are  good  reasons  for  recording  our 
emerging  design.  One  of  the  main  reasons  is  that  we  are 
interested  in  the  methodology  of  design  (as  well  as  the  design 
itself)  of  large  software  systems  [ Zurcher  and  Randell  1968]. 
There  are  few  available  records  of  the  intermediate  stages  of 
design  of  an  operating  system;  this  Status  Report  together  with 
the  Project  Workbook  will  provide  such  records.  The  other 
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principle  reason  is  to  satisfy  a 
explain  our  solutions  to  problems  in 
such  as  interprocess  communication, 
and  specification  of  an  implementation 


number  of  requests  that  we 
operating  system  design 
management  of  I/O  devices, 
language. 
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2.  STRUCTURE  OF  THE  NUCLEUS 


2.1  Project  Goals 

It  is  the  intention  of  Project  SUE  to  construct  an 
operating  system  which  is  reliable,  efficient,  and  extensible. 
This  goal  may  appear  to  be  difficult,  as  an  improvement  in  any 
one  of  these  properties  often  results  in  a  degradation  in 
another.  However,  all  three  of  these  properties  are  enhanced  by 
insisting  upon  a  simple  and  understandable  structure  for  the 
system.  (Where  such  a  trade-off  has  appeared  to  be  unavoidable 
in  the  system  design,  we  have  generally  attempted  to  improve 
reliability  and  extensibility,  when  this  could  be  accomplished 
at  a  modest  price  in  efficiency.) 

2.1.1  Reliability  To  have  a  reliable  system,  we  must  know  what 
the  system  is  required  to  do.  Once  we  know  what  is  required  of 
the  system,  we  need  some  way  of  guaranteeing  that  the  system 
behaves  correctly  (according  to  specifications) .  We  can  hope  to 
understand  (and  prove  correct)  the  behaviour  of  a  large  software 
system  only  if  it  has  been  designed  with  this  need  for 
understandability  clearly  in  mind.  Thus  we  have  attempted  to 
design  simple  (yet  powerful)  facilities,  each  implemented  by  a 
module  within  our  system,  and  to  provide  a  stringent  and 
straightforward  framework  whereby  the  various  subsystems  may 
interact.  Not  only  does  this  simple  and  stringent  structure 
enhance  our  understanding,  it  also  provides  natural  firewalls  to 
localize  failures.  For  example,  if  a  critical  facility  is 
provided  by  a  subsystem,  that  subsystem  must  carefully  protect 
its  ability  to  continue  providing  that  facility,  reyardless  of 
the  unreliability  of  some  of  its  users;  this  holding  action 
limits  the  spread  of  disaster. 

2.1.2  Efficiency  To  have  an  efficient  system,  we  must  be  able 
to  tune  the  system  to  match  whatever  environment  it  finds  itself 
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in.  Experience  has  shown  that  it  is  not  generally  possible  to 
construct  an  operating  system  so  that  it  will  be  tuned  across  a 
variety  of  applications.  Within  the  SUE  system  Nucleus  we  have 
attempted  to  implement  powerful  and  convenient  methods  for 
managing  resources,  while  leaving  the  allocation  strategies 
(which  use  the  resource  management  facilities)  outside  the 
Nucleus,  where  they  can  be  easily  adjusted  (or  built)  for  a 
particular  installation,  or  for  a  subsystem  executing  under  the 
SUE  system. 

As  we  shall  see,  the  definition  of  the  resources  of  the 
system  (and  which  subsystems  use  what  resources)  is  exactly  what 

is  meant  by  the  term  system _ structure.  The  system  structure 

defines  logical  resources  whose  properties  are  simple  enough 
that  an  installation  (or  subsystem)  can  afford  to  make  efficient 
use  of  them.  (Contrast  this  with  a  poorly  structured  system  in 
which  changing  an  allocation  strategy  costs  both  reliability 
(due  to  untorseen  side  effects)  and  a  large  systems  programming 
effort.}  We  have  tried  to  avoid  mechanisms  which  would  gain  a 
small  amount  in  efficiency  within  a  subsystem  at  the  price  of 
flexibility  in  global  allocation  strategies. 


2.1.3  Extensibility  To  have  an  extensible  system,  we  must 
provide  our  users  with  a  range  of  powerful  and  flexible 
facilities.  We  are  submitting  the  facilities  of  our  system  to  a 
rigourous  test,  namely,  we  will  implement  the  entire  system 
(with  the  exception  of  the  innermost  12K  or  so  bytes  of  code 
called  the  Kernel)  with  exactly  the  facilities  provided  by  the 
Kernel.  This  has  the  welcome  benefit  of  allowing  us  to  test 
different  versions  of  a  SUE  system  under  a  SUE  system .  A  simple 
and  stringent  structure  allows  us  to  specify  in  a  reasonable  way 
what  facilities  our  system  uses  and  what  facilities  our  system 
provides. 


2.2  S tr uct ure-Enf or ci ng_Conv en t ions 

We  have  used  three  main  tools  to  help  us  in  structuring  the 
SUE  system:  (1)  hierarchical  levels  of  virtual  machines;  (2) 
asynchronous  entities,  called  processes;  and  (3)  tightly 
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controlled  communication  among  processes.  We  will  discuss  each 
of  these  briefly. 

2.2.1  Hierarchical  Levels  of  Virtual  Machines  We  have  borrowed 
Dijkstra's  and  Habermann's  ideas  about  hierarchical  systems 
[  1968,  1967].  The  SUE  system  will  be  constructed  by  adding  one 
layer  of  software  at  a  time.  Each  layer  may  be  thought  of  as 
creating  logical  facilities  (or  resources)  which  can  be  used  by 
successive  layers  of  software.  Thus,  each  layer  of  software  can 
be  designed  (and  validated)  on  the  assumption  that  it  executes 
on  the  virtual  machine  defined  by  the  resources  created  by 
previous  layers.  For  example,  the  original  layer  in  our  system 
is  the  System/360  hardware.  The  first  layer  of  software  (the 
Kernel)  uses  the  clock  to  implement  multiple  processes  (i.e.,  to 
simulate  virtual  machines  such  that  each  process  has  its  own 
CPU).  A  successive  layer  will  be  the  Channel  I/O  System;  this 
layer  will  implement  logical  control  units,  which  will  be  used 
by  another  layer  to  construct  the  Disk  I/O  System,  and  so  on. 

2.2.2  Asynchronous  Processes  All  of  the  SUE  system  will  be 
implemented  as  processes  (except  the  Kernel,  which  implements 
processes) .  A  process  is,  essentially,  a  virtual  CPU  which  can 
execute  instructions  of  the  System/360  order  code  {not  including 
the  priveleged  (supervisor  state)  instructions},  and 
instructions  called  primitives,  which  are  implemented  by  the 
Kernel.  We  borrow  Dijkstra's  idea  that  each  asynchronous  piece 
of  hardware  can  be  most  conveniently  and  understandably  managed 
by  a  process;  the  managing  process  is  synchronized  with  the 
piece  of  hardware  and  has  sole  responsibility  for  initiating  and 
responding  to  actions  on  the  piece  of  hardware.  Thus,  the 
(unfortunately  complex)  family  of  asynchronous  System/360 
hardware  units,  which  includes  channels,  control  units,  and 
devices,  is  mirrored  by  a  corresponding  family  of  asynchronous 
software  processes. 

We  have  used  processes  for  another  purpose  which  is 
sometimes  quite  distinct  from  asy nchronism :  they  are  the 
entities  to  which  we  assign  rights  to  use  (logical)  resources  of 
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the  system.  For  example,  we  associate  with  each  process  the 
ability  to  execute  only  a  certain  subset  of  the  primitives 
implemented  by  the  Kernel.  It  would  have  been  possible  to 
implement  a  protection  mechanism  (a  control  of  rights  to 
facilities) ,  which  assigned  rights  to  domains  instead  of  to 
processes  [ Lampson  1971,  Graham  1971],  The  rights  of  a  process 
to  access  facilities  would  change  as  the  process  executed  first 
in  one  protection  domain,  and  then,  later,  in  another.  We  have 
chosen  to  merge  the  concepts  of  domains  and  processes  because  we 
feel  that  in  most  cases  the  two  will  be  identical. 

2.2.3  Tig.h tlx_Controlled_Int erprocess_Communica tion  It  will  be 
possible  to  extend  the  SUE  system  for  a  large  number  of 

distinctly  different  applications.  We  wish  to  be  able  to 

guarantee  that  an  extension  will  not  be  able  to  destroy  existing 
subsystems.  This  guarantee  will  be  possible  because  we  can 

insulate  a  new  subsystem,  so  that  it  can  not  tamper  with  (or 

send  messages  to)  any  other  existing  subsystem.  Processes 
communicate  with  each  other  only  through  a  set  of  ports  (fixed 
at  process  creation  time)  which  are  connected  (at  run  time)  to  a 
set  of  mailboxes.  (Here  we  have  borrowed  vocabulary  from  Wulf 
[  1971].)  Permission  to  connect  ports  to  mailboxes  is  carefully 
regulated  by  the  Kernel;  in  general,  subsystems  can  connect 
their  own  ports  only  to  their  own  mailboxes,  and  thus  can  not 
bother  (or  be  bothered  by)  other  subsystems.  Allowing  processes 
to  communicate  only  through  ports  has  numerous  advantages 
including  the  following; 

(1)  It  may  be  slow  to  connect  a  port  to  a  mailbox. 
However,  once  the  connection  has  been  made, 
interprocess  communication  is  quite  fast  because  little 
checking  or  searching  is  required  for  each  message. 
(Presumably,  most  checking  and  searching  was  done  at 
connect  time.) 

Interaction  between  any  two  processes  can  be  monitored 
by  inserting  a  ’'wire  tapping”  process  into  their 
communication  path.  (Of  course,  the  ability  to  tap 
wires  is  closely  regulated.) 


(2) 
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(3)  Processes  will  be  able  to  wait  for  each  other  only  via 
ports.  Hence,  the  logic  required  to  prevent  (or 
detect)  deadlock  should  be  simple  [Verner  1971]. 

2.3  Kernel  and  Nucleus 

There  are  two  particularly  important  hierarchical  levels  in 
the  SUE  system:  the  Kernel  and  the  Nucleus. 

The  Kernel  is  the  first  layer  of  software  added  to  the 
hardware;  its  primary  purpose  is  to  implement  processes.  All 
processes  are  insulated  (by  the  Kernel)  from  such  System/360 
idiosyncracies  as  interrupts,  the  Start  I/O  instruction,  the 
memory  key  instructions,  etc.  This  guarantees  that  every 
process  in  the  system  can  run  in  problem  state  with  a  non- 
privileged  memory  key.  Of  course,  the  Kernel  will  provide 
facilities  for  interrogating  the  clock,  initiating  I/O, 
manipulating  memory  keys,  etc.,  but  these  facilities  will  be 
carefully  controlled,  with  no  process  being  forced  or  permitted 
to  have  more  facilities  than  it  requires  to  perform  its 
function. 

This  means  that  certain  real-time  applications  have  been 
ruled  out.  The  Kernel  insists  upon  handling  all  interrupts  and 
scheduling  CPU  time  for  all  processes.  Thus,  a  response  time  of 
less  than  that  required  to  execute  10  to  100  instructions  on  the 
System/360  (e.g.,  100  microseconds  on  the  360/65)  cannot  be 
provided.  Such  a  fast  response  would  be  possible  only  by 

sacrificing  the  convenience,  understandabilit y,  and  reliability 
of  the  Kernel. 

The  Nucleus  forms  the  basis  of  application  subsystems  which 
might  include  an  interactive  terminal  system  or  a  batch 

processing  system.  (Our  concept  of  a  nucleus  corresponds 

closely  to  that  of  Brinch  Hansen  [1970].)  The  Nucleus  provides 

the  following  facilities: 

(1)  A  basic  file  system; 

(2)  High  level  communication  with  peripheral  devices; 

(3)  An  accounting  system; 

(4)  A  basic  console  system. 
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It  is  intended  that  the  Nucleus  will  provide  conve 
level  mechanisms  which  can  be  used  for  managing  the  r 
the  system.  Resource  allocation  strategies  will  be 
by  subsystems  which  are  outside  the  Nucleus. 


2.4  Subsys tem s_ wit hi n_the_ Nucleus 

We  will  now  discuss  the  major  subsystems  in  t 
(see  Figure  2.4-1),  and  how  they  interact.  That 
present  the  structure  of  the  Nucleus.  Each  subsystem 
Nucleus  implements  a  facility  (logical  resource), 
is  intended  to  be  hierarchical;  this  means  that  no  su 
allowed  to  use  (even  in  an  indirect  fashion)  the 
which  it  creates.  This  gives  us  a  natural  order  of 
the  subsystems  of  the  Nucleus:  first  we  present  subsy 
use  on  iy  the  facilities  provided  by  the  Kernel, 
successively  present  those  subsystems  which  use  only 
provided  by  previously  presented  subsystems. 


nient  high 
esources  of 
implemented 


he  Nucleus 
is,  we  will 
within  the 
The  Nucleus 
bsystem  is 
f acilit ies 
present ing 
stems  which 
Then  we 
f acilit ies 


2.4.1  Ultimate  Ancestor  This  is  a  single  process  which  is  the 
root  of  the  family  of  processes  making  up  the  SUE  system.  This 
process  is  allocated  all  the  resources  provided  by  the  Kernel, 
and  it  passes  these  resources  out  to  other  processes.  These 


r  esou 

rces 

include 

CPU  speed 

and 

time,  mem 

ory,  channels,  and 

the 

abili 

ty 

to  use 

each  of 

the 

various 

Kernel 

primi ti ves. 

The 

Ultim 

ate 

Ancestor 

implements 

an 

Archconso 

le ,  a 

logical  device 

which  is  used  by  processes  within  the  Nucleus  to  communicate 
with  the  operator.  For  example,  a  Nucleus  process  which  detects 
an  uncor rectable  failure  in  the  I/O  hardware  will  report  this 
fact  to  the  Ultimate  AncestoL,  which  will  use  the  Archconsole  to 
report  to  the  operator. 


Archconsole 


Logical  Control 
Units 


Logical  Disks 
Logical  Volumes 

Disk  Files 
Sponsors 


Logical  Printers, 
Readers,  Punches, 
Tape  Drives 

Logical 

Typewriters 


Nucleus  Consoles 


Figure  2,4-1  The  Hierarchical  Structurg_of  the  SUE  Nucleus 
Each  box  corresponds  to  a  major  subsystem  within  the  SUE 
Nucleus.  Each  subsystem  uses  some  logical  resources  and  creates 
others.  The  edges  indicate  subsystems  which  use  logical 
resources  created  by  other  subsystems.  (Not  all  edges  are 
drawn.)  Logical  resources  created  by  each  subsystem  are  shown 
in  the  left  margin. 
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this  violation  will  not  result  in  an 
adlock. 
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2.4.2  Channel _ I/O _ System  This  subsystem  consists  of  one 

process,  a  Channel  Manager,  for  each  System/360  hardware 
channel.  Logically,  each  Channel  Manager  will  initiate  I/O  on 
its  channel  by  sending  a  message  to  the  channel  and  will  receive 
notification  that  the  I/O  is  complete  by  receiving  a  message 
from  the  channel.  That  is,  the  Channel  Managers  are  written 
using  exactly  the  same  communication  logic  (message  passing) 
used  by  all  processes.  In  fact,  this  communication  to  the 
channels  will  be  accomplished  by  special  purpose  primitives 
(implemented  by  the  Kernel  I/O  Manager)  which  are  equivalent  to 
"start  I/O"  and  "wait  for  interrupt"  on  the  channel.  A  Channel 
Manager  reports  channel  failures  to  the  Ultimate  Ancestor.  The 
Channel  Managers  implement  logical  control  units;  subsystems 
communicating  with  a  Channel  Manager  can  behave  as  though  they 
are  sending  messages  directly  to  a  control  unit,  and  are 
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receiving  answers  from  it.  Therefore,  it  is  a  Channel  Manager* s 
job  to  sort  out  the  interrupts  it  receives,  acting  on  those 
applying  only  to  channel  conditions,  and  passing  others  down  to 
the  relevant  Control  Dnit  Managers. 

2.4.3  Disk  I/O  System  and  Disk  Volume _ Manager  This  subsystem 

consists  of  two  closely  cooperating  modules.  The  Disk  I/O 
System  consists  of  one  process  (a  Control  Unit  Manager)  for  each 
disk  control  unit  and  one  process  (a  Device  Manager)  for  each 
disk  drive.  The  logical  control  units  provided  by  the  Channel 
Managers  are  used  to  implement  logical  disks.  Each  logical  disk 
will  accept  high-level  commands  including: 

(1)  Format  a  disk  to  standard  SUE  format; 

(2)  Read  or  write  a  volume  label; 

(3)  Write  n  contiguous  2K  blocks  from  memory  to  disk; 

(4)  Read  n  contiguous  2K  blocks  from  disk  to  memory. 

There  are  two  message  paths  to  a  logical  disk.  One  is  a 
control  path :  this  path  accepts  the  commands  for  disk  formatting 
and  volume  labeling  and  transmits  any  indications  of  possible 
disk  pack  switches.  (Any  possible  pack  switch  suspends 
operation  of  the  logical  disk  until  there  is  an  explicit  restart 
via  the  control  path.)  The  second  path  is  the  communication 
£ath  which  receives  the  read  and  write  commands. 

There  is  one  logical  disk  implemented  for  each  System/360 
disk  drive  on  the  system.  However,  a  logical  disk  does  not 
correspond  to  a  fixed  physical  drive.  Rather,  a  logical  disk 
may  be  switched  from  one  physical  drive  to  another  by  a  control 
command  from  the  Disk  Volume  Manager  to  its  Control  Unit 
Manager.  It  is  presumed  that  these  switches  will  occur  only 
when  a  physical  disk  drive  fails  or  the  operator  chooses  to  move 
a  volume  which  is  in  use  to  a  different  drive. 

The  Disk  Volume  Manager  is  closely  integrated  with  the  Disk 
I/O  System.  It  has  exclusive  rights  to  the  control  paths  to  the 
disk  Device  Managers  and  to  the  disk  Control  Unit  Managers.  It 
uses  these  control  paths,  together  with  communication  with  the 
operator  (via  the  Archconsole) ,  to  maintain  the  correct  volumes 
(disk  packs)  on  the  correct  logical  disks.  The  Disk  Volume 
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Manager  implements  the  facilities  for  mounting  (and  maintaining) 
a  volume  on  a  given  logical  disk  drive. 

To  summarize,  the  Disk.  I/O  System  and  Disk  Volume  Manager 
implement  logical  disks  and  a  facility  for  mounting  disk 
volumes. 

2.4.4  Basic  File  System  and_Banker  This  subsystem  (actually  two 
closely  related  modules)  uses  logical  disks  to  implement  Disk 
Files  and  Sponsors.  It  is  possible  that  the  Basic  File  System 
will  be  the  exclusive  user  of  the  Disk  I/O  and  Volume  Manager 
Systems;  however,  we  have  maintained  the  ability  to  construct  a 
separate  (and  incompatable)  file  system  without  doing  violence 
to  the  Nucleus  structure.  The  Basic  File  System  provides 
facilities  for: 

(1)  Creating  and  destroying  Disk  Files; 

(2)  Opening  and  closing  Disk  Files; 

(3)  Reading  and  writing  Disk  Files. 

Commands  to  an  open  file  include: 

(1)  Read  n  contiguous  2K  blocks  from  file  to  memory; 

(2)  Write  n  contiguous  2K  blocks  from  memory  to  file. 

The  Banker  implements  (disk  resident)  structures  called 
Sponsors.  Each  Sponsor  represents  the  ability  to  finance  a 
certain  amount  of  activity  by  processes.  The  Sponsor  structure 
is  used  for  recording  accounting  and  protection  information  that 
is  to  be  maintained  beyond  the  death  of  individual  processes. 
It  should  be  mentioned  that,  while  the  Banker  provides  an 
accounting  of  the  use  of  Nucleus  resources,  it  does  not  do 
billing.  Billing  will  be  done  by  a  subsystem  outside  of  the  SUE 
Nucleus,  which  uses  the  Banker's  records  to  calculate  charges. 
(We  do  not  intend  to  enforce  a  standard  billing  system.) 

In  brief,  Basic  File  System  and  the  Banker  implement 
convenient  facilities  for  using  disk  storage  and  for  regulating 
and  accounting  for  the  activities  of  processes. 


2.4.5  Peripheral _ I/O _ System  This  subsystem  manages  all 

System/360  hardware  devices  except  the  disks  and  the  typewriter¬ 
like  devices.  It  uses  the  logical  control  units  provided  by  the 


Channel 
devices : 
(1) 
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Managers  to  implement  the  following  logical  peripheral 

Printers — Commands  to  a  logical  printer  include: 

Print  n  contiguous  lines  from  memory. 

(2)  Card  readers--Commands  to  a  logical  card  reader 
include: 

Read  n  contiguous  cards  to  memory. 

(3)  Card  punches — Commands  to  a  logical  punch  include: 

Punch  n  contiguous  cards  from  memory. 

(4)  Magnetic  Tape  Dr ives--Commands  to  a  logical  tape  drive 
include: 

Read  and  write  volume  label. 

Read  n  contiguous  blocks  from  tape  to  memory. 

Write  n  contiguous  blocks  from  memory  to  tape. 

Each  asynchronous  control  unit  or  device  will  have  a 
corresponding  process  which  will  be  its  manager.  The  Peripheral 
I/O  System  will  use  the  Basic  File  System  to  read  in  extra  code 
to  handle  any  unusual  circumstances  on  its  devices.  Failure  to 
recover  from  such  circumstances  will  be  reported  to  the  Ultimate 
Ancestor. 

2.4.6  Typewriter  I/O  System,  Typewriter _ Listener , _ and _ Message 

Switcher  This  subsystem  is  made  up  of  three  closely  cooperating 
modules.  It  uses  the  logical  control  units  provided  by  the 
Channel  Managers  to  implement  a  telephone  answering  and 
switching  service.  All  typewriter-like  devices  (including  the 
CPU  aaster  console)  will  be  treated  as  if  they  were  dial-up 
devices.  Thus,  each  typewriter  acts  as  a  telephone  which  can 
dial  up  SUE  and  then  can  hang  up  on  SUE.  (The  hanging  up  of  the 
typewriter  which  is  acting  as  the  Archconsole  is  a  serious 
matter  to  be  taken  up  by  the  Ultimate  Ancestor.) 

The  Typewriter  I/O  System  uses  the  logical  control  units 
provided  by  the  Channel  Managers  to  implement  logical 
typewriters.  Like  a  logical  disk,  a  logical  typewriter  has  two 
message  paths,  a  control  path  and  a  communication  path.  The 
control  path  is  used  primarily  to  inform  the  Typewriter  Listener 
when  a  typewriter  dials  up  or  hangs  up.  The  communication  path 
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the  following  behaviour.  It  can  be  sent  a 
or  a  "hang  up".  In  reply  to  a  read,  it  can 
"hang  up".  ("Hang  ups"  in  either  direction 
eported  on  the  control  path,  and  the  logical 
its  operation.) 

Listener  reads  the  first  line  transmitted 
p)  by  a  logical  typewriter  and  decides  which 
any)  should  converse  with  the  logical 
xactly  one  such  subsystem  is  found,  then  the 
is  hooded  directly  to  that  subsystem.  If 
ystem  is  to  be  hooked  to  the  typewriter,  then 
ener  determines  from  the  typewriter  how  the 
each  subsystem  are  to  be  distinguished.  The 
then  hooks  the  typewriter  to  the  Message 
ssage  Switcher  to  each  subsystem.  It  is  then 
her's  job  to  route  each  line  from  the 
orrect  subsystem. 

this  subsystem  (composed  of  the  Typewriter 
ewrit.er  Listener,  and  Message  Switcher) 
dial-up  typewriters  for  use  by  succeeding 


2.4.7  Special_Con dition_Man ager  This  subsystem  has  the  unique 
purpose  of  providing  a  communication  path  from  the  Ultimate 
Ancestor  to  media  external  to  memory.  The  Ultimate  Ancestor 
violates  the  hierarchical  structuring  rule  by  being  the  (unique) 
user  of  this  subsystem's  facilities.  The  Special  Condition 
Manager  uses  a  logical  typewriter  to  communicate  with  the 
operator.  The  Ultimate  Ancestor  implements  the  Archconsole  by 
talking  to  the  operator  via  this  link.  (Needless  to  say,  a 
logical  typewriter  who  claims  to  represent  the  operator  is 
carefully  queried  before  being  accepted.)  The  reliability  of 
the  hardware  path  to  the  operator  is  monitored  by  the  Ultimate 
Ancestor;  when  this  path  fails,  the  Ultimate  Ancestor  will 
request  that  the  Special  Condition  Manager  attempt  to  establish 
a  new  path  to  the  operator.  The  Special  Condition  Manager  may 
also  be  responsible  for  writing  to  disk  files  (or  possibly  to 
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peripheral  devices)  a  record  of  hardware  and  software  failures. 

2.4.8  Nucleus_Console _ System  This  subsystem  implements  SUE 

Nucleus  Consoles,  which  allow  persons  at  typewriters  to  use 
facilities  provided  by  the  Nucleus.  Such  a  console  provides  a 
person  with  facilities  to: 

(D  Create,  destroy,  start,  stop,  and  inspect  processes; 

(2)  Load  a  program  from  a  Disk  File  and  have  it  execute, 
i.e.,  start  a  new  subsystem; 

(3)  Connect  ports  of  processes. 

It  is  intended  that  the  use  of  Nucleus  Consoles  be  limited 
to  persons  of  system  programmer  caliber. 

This  subsystem  uses  logical  typewriters.  Sponsors  (to  see 
which  facilities  a  person  has  rights  to),  and  Disk  Files,  to 
create  a  logical  resource  called  Nucleus  Consoles.  These 
logical  resources  are  used  by  subsystems  called  people. 
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3.  KERNEL 


3.1  Function 


the  Kernel  in  the 

SUE  operating 

system 

is 
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CPU 
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maintain 
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represen tdtion  of  each  process  in  the  system  at  any  point  in 
time.  The  data  structures  used  for  this  purpose  cannot  be 
directly  altered  by  the  process  that  it  represents  or  by  any 
other  process,  either  accidentally  or  deliberately.  Processes 
are  structured  in  a  family  tree.  This  hierarchical  structuring 
is  used  for  protection;  the  resources  owned  by  a  family  are 
limited  to  the  original  resources  of  that  family’s  root  process. 

The  Kernel  implements  processes,  and  these  processes  will 
in  general  have  to  cooperate  with  each  other.  "Cooperate”  is 
used  in  the  sense  that  they  must  be  able  to  activate  one  another 
and  exchange  information.  Thus,  process  synchronization  is  a 
facility  provided  by  the  Kernel.  Since  processes  can  create  and 
destroy  sons,  generate  program  interrupts,  pass  resources,  and 
indirectly  generate  I/O  activity,  the  Kernel  must  manage  memory, 
traps,  access  to  resources,  the  clock,  short-term  CPU 
scheduling,  I/O  commands,  and  interrupts. 

The  Kernel  differs  from  the  processes  it  implements  in 
several  respects: 

(1)  It  may  use  the  privileged  System/360  instructions; 

(2)  It  may  operate  with  the  System/360  system  mask  off 
(i.e.,  it  may  inhibit  I/O  and  external  interrupts); 

(3)  It  may  operate  in  the  priveleged  memory  protection  key 
(key  zero)  ; 

(4)  It  has  access  to  the  System/360  permanent  storage 
assignments ; 

(5)  It  is  activated  solely  by  System/360  interrupts, 
fact  not  a  process,  but  rather  it  is  the  first 


The  Kernel  is  in 


19 


extension  of  the  hardware.  The  Kernel  can  be  considered  to  be 
that  collection  of  programs  which  implements  a  variable  number 
of  virtual  processors.  These  virtual  processors  (processes)  are 
more  sophisticated  than  the  base  machine  (the  System/360 
hardware)  in  that  they  can  execute  the  SUE  primitives  as  well  as 
the  (non-privileged)  System/360  instruction  set. 

3.2  Process-State  Transitions 

Each  process  in  the  system  is  represented  by  a  Process 
Descriptor.  This  data  structure  contains  information  relating 
to  the  identification,  family,  resources,  etc.,  of  the  process, 
as  well  as  two  state  variables.  These  state  variables  define 
the  Stop  State  and  the  Wait  State  of  the  process,  and  can  be 
altered  by  the  following  primitives: 

(1)  Create  Process; 

(2)  Start  Process; 

(3)  Send ; 

(4)  Receive; 

(5)  Stop  Process; 

(6)  Destroy  Process. 

The  Stop  State  of  a  process  can  take  on  the  value  (Not  Stopped) , 
(Stopped  By  Father),  or  (Stopped  By  Ancestor).  The  Wait  State 
can  take  the  value  (Not  Waiting) ,  (Waiting  For  Message) ,  or 
(Waiting  With  Message  Available) .  All  combinations  of  Stop  and 
Wait  States  are  valid  with  the  exception  of  (Not  Stopped, 
Waiting  With  Message  Available) . 

A  process  in  the  state  (Not  Stopped,  Not  Waiting)  is  ready 
and  will  be  allocated  CPU  time.  Processes  in  other  states  are 
blocked. 

A  process  is  created  when  its  father  invokes  the  Create 
Process  primitive.  The  son  process  is  created  in  the  state 
(Stopped  By  Father,  Not  Waiting)  (see  Figure  3.2-1).  The 
process  becomes  a  candidate  for  CPU  time  when  its  father  refers 
to  it  as  a  parameter  to  the  Start  Process  primitive,  as  this 
places  it  in  the  state  (Not  Stopped,  Not  Waiting) .  If  during 
execution,  the  process  invokes  the  Receive  primitive  (indicating 
that  it  wants  information  from  another  process) ,  one  of  the 
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following  two  things  will  happen:  If  a  niessag 
this  process,  the  process  receives  the  me 
execution;  if,  however,  there  is  no  message 
requesting  process,  and  the  requesting  pr 
that  it  wishes  to  wait  if  no  message  is  avail 
enters  the  state  (Not  Stopped,  Waiting 
process  is  now  blocked  (i.e.,  is  not  a  candid 
until  some  process  sends  the  required  rnessa 
the  message,  the  process  becomes  unblocked  as 
state  (Not  Stopped,  Not  Waiting) . 

The  execution  of  a  process  can  also  b 
father  or  one  of  its  ancestors.  If  a  fath 
his  sons  in  an  invocation  of  Stop  Process,  th 
goes  from  (Not  Stopped)  to  (Stopped  by  Fat 
all  of  that  son's  descendants  which  have  a  St 
Stopped)  will  be  given  a  Stop  State  of  (St 
This  situation  may  be  complicated  by  the  fact 
stopped  processes  may  have  had  a  Wait  St 
Message).  In  this  case,  if  a  message  arrives 
processes,  its  Wait  State  becomes  (Wai 
Available).  If  the  father  or  ancestor  now 
Process  primitive,  then  those  processes  whi 
by  the  earlier  invocation  of  Stop  Process  go 
Stopped,  Not  Waiting).  The  problems  invol 
starting  processes  are  further  described  in  S 
the  primitives  are  discussed  in  detail, 
transition  diagram  is  provided  in  Figure  3.2- 
the  state  (Stopped  By  Father) ,  together 
descendants,  will  be  removed  from  the  system 
invokes  the  Destroy  Process  primitive. 
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Figure  3.2-1  Process  state  transitions 
This  shows  the  changes  of  state  of  process  D,  who 
father  B#  a  grandfather  A,  and  a  brother  C. 
presently  communicating  with  process  X. 
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3 . 3  Ker nel_ Struct ure 

The  Kernel  exhibits  a  hierarchical  structure  reflecting  a 

more  powerful  virtual  machines.  It 
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channels. 

The  Trap  Manager  provides  subsequent  levels  with  a  virtual 
machine  which  can  differentiate  between  exceptional  conditions 
which  a  process  has  expected,  and  exceptional  conditions  which 
were  not  expected.  The  Trap  Manager  is  invoked  either  by  a 
process  which  causes  a  System/360  program  interrupt,  such  as 
specification  exception,  or  by  the  Primitive  Manager  within  the 
Kernel  (as  explained  later) .  The  Trap  Manager  consists  of  three 
sections: 

(1)  The  trap  mask  inspector; 

(2)  The  trap  handler; 

(3)  The  trap  error  handler. 

The  trap  mask  inspector  determines  whether  or  not  the 
process  was  expecting  the  exceptional  condition  that  occurred. 
If  it  was,  control  is  passed  to  the  trap  handler,  otherwise  the 
trap  error  handler  receives  control. 

The  trap  handler  resets  the  trap  mask  of  the  trap-causing 
process  to  null,  and  then  passes  control  to  the  "user  trap 
handler".  If  an  error  occurs  while  this  is  being  done,  control 
is  passed  to  the  trap  error  handler. 

The  trap  error  handler  places  the  process  which  caused  the 
exceptional  condition  into  the  Stop  State  (Stopped  By  Father) , 
and  all  of  its  descendants  into  the  Stop  State  (Stopped  By 
Ancestor).  This  may,  of  course,  involve  using  the  Short-Term 
Scheduler  to  remove  some  processes  from  the  Heady  Queue.  When 
this  has  been  done,  the  father  of  the  process  which  caused  the 
trap  is  notified  of  the  situation. 

The  second  section  of  the  level  3  machine  consists  of  the 
Kernel  I/O  Manager,  which  implements  logical  channels.  The 
functions  of  this  module  are: 

(1)  to  execute  the  Systera/360  I/O  instructions  for  the 
Channel  Managers; 

(2)  to  convert  asynchronous  I/O  interrupts  into  messages; 

(3)  to  insure  interrupts  are  not  lost. 

Since  the  second  of  these  functions  may  involve  the  activation 
of  a  process,  the  Kernel  I/O  Manager  makes  use  of  the  facilities 
provided  by  the  Short-Term  Scheduler.  The  logical  channels  are 
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available  to  processes  via  level 
noted  that  the  Kernel  I/O  Manager 
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The  outmost  layer  of  the  Kernel  (level  4)  is  the  Primitive 
Manager.  This  level  is  composed  of  that  collection  of  programs 
which  implements  operations  that  processes  will  view  as 
primitive  machine"  functions.  (Primitives  are  invoked  by 
executing  a  Supervisor  Call  instruction.)  These  primitives 
provide  processes  with  racilities  for  managing  processes,  traps, 
capabilities,  memory,  and  the  clock.  A  process  can  request  that 
all  invocations  of  primitives  be  trapped.  If  this  situation 
exists,  the  Primitive  Manager  completes  its  work  by  invoking  the 
trap  handler.  If  primitives  are  not  to  be  trapped,  the 
Primitive  Manager  attempts  to  invoke  the  procedure  which  effects 
the  functions  associated  with  the  desired  primitive.  This 
action  will  invoke  the  trap  handler  if  the  Supervisor  Call 
number  does  not  correspond  to  a  valid  primitive. 

A  procedure  which  implements  a  given  primitive  is  called  a 
primitive  handler.  When  it  receives  control  from  the  Primitive 
Manager,  it  is  passed  a  pointer  to  the  parameters  passed  to  the 
primitive.  If  the  parameters  are  invalid,  the  Trap  Manager  is 
invoked,  otherwise,  the  result  (return  code)  is  returned  to  the 
invoking  process. 

We  have  described  the  structure  of  the  SUE  Kernel  in  terms 
of  a  four-level  hierarchy.  Level  1  is  the  Clock  Manager,  which 
implements  an  alarm  clock.  The  Short-Term  Scheduler,  residing 
on  level  2,  uses  the  clock  in  order  to  implement  processes.  The 
Short-Term  Scheduler  is  used  by  both  levels  3  and  4  of  the 
Kernel,  since  it  provides  the  facility  to  merge  processes  into, 
and  remove  processes  from,  the  Ready  Queue.  Level  3  of  the 
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Kernel  consists  of  two  disjoint  sections,  the  first  being  the 
Trap  Manager  which  handles  expected  and  unexpected  interrupts, 
and  the  second  the  Kernel  I/O  Manager  which  implements  logical 
channels.  Level  4  of  the  hierarchy  is  the  Primitive  Manager. 

3.4  A  Preliminary  Look  at  Kernel  Data, Structures 

There  are  four  data  structures  which  are  associated  with 
each  process,  namely,  the  Process  Descriptor,  the  Port 
Descriptor,  mailboxes,  and  the  Capability  List. 

The  £rocess_De script or  is  the  main  data  structure  in  the 
Kernel.  All  other  data  structures  associated  with  a  process  can 
be  located  through  its  Process  Descriptor.  The  Process 
Descriptor  also  contains  entries  which  define  the 
identification,  state,  trap  intormation,  family  links, 
resources,  and  queueing  links  of  the  process.  Every  process  in 
the  system  has  a  Process  Descriptor. 

Process  synchronization  and  the  sharing  of  information  is 
accomplished  by  message  passing.  A  process  sends  information 
through  one  of  its  £orts  into  a  mailbox^  The  information 
resides  there  until  the  process  on  the  other  side  of  the  mailbox 
asks  for  it.  At  this  time  the  information  is  transferred  from 
the  mailbox  into  an  area  specified  by  the  receiving  process. 

The  number  of  ports  that  a  process  has  remains  fixed  from 
the  time  the  process  is  created.  The  Port  Descriptor  is  an 
array  of  elements,  each  associated  with  a  port.  Each  element 
defines  the  location  of  its  associated  mailbox  and  indicates 
whether  or  not  the  process  is  waiting  through  that  port.  A 
mailbox  consists  of  two  data  structures:  a  fixed  length  Mailbox 
Header;  and  a  variable  length  Mailbox  B pd y .  A  Mailbox  Body  will 
contain  a  number  of  mailbox  slots^  Each  mailbox  slot  can  hold 
one  message. 

A  process  is  allowed  to  create  a  maximum  number  of 
mailboxes,  where  the  number  is  defined  when  the  process  is 
created.  When  a  process  creates  a  mailbox,  it  can  specify  the 
size  of  the  messages  that  will  be  passed  through  the  mailbox  and 
also  the  number  of  messages  that  can  simultaneously  reside  in 
the  mailbox  (slot  size  and  number  of  slots,  respectively) . 
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The  ability  of  a  process  to  access  resources  is 
by  Kernel  data  structures  called  capabilities^  A 
created  by  its  father  with  certain  capabilities,  a 
receive  other  capabilities  during  conversations 
processes.  Processes  cannot  modify  capabilities  dir 
they  may  request  that  the  Kernel  perform  certain  ope 
them.  The  capabilities  associated  with  any  particul 
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3.5  Primitives 

Functional  specifications  presently  exist  for  th 
five  groups  of  primitives: 

(1)  Process  management; 

(2)  Synchronization  and  message  passing; 

(3)  Trap  management; 

(4)  Capability  management; 

(5)  Memory  management. 

We  understand  the  above  groups  and  have  begun  to  co 
into  code.  There  are  some  other  areas  which  w 
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managed  using  six  primitives: 

(1)  Create  Process; 

(2)  Destroy  Process; 

(3)  Start  Process; 

(4)  Stop  Process; 

(5)  Inspect  Process; 

(6)  Modify  Process. 
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Create  Process 

A  process  may  create  a  son  by  invoking  this  primitive.  The 
call  results  in  the  creation  of  a  new  process  with  the  given 
specifications.  The  new  process  is  initialized  with  a  certain 
set  of  default  resources  in  addition  to  those  explicitly  given. 
Any  resources  given  out  to  the  new  process  are  subtracted  from 
the  resources  of  the  invoking  process.  The  new  process  is 
termed  a  son  of  the  creating  process  and  is  created  in  the  state 
(Stopped  By  Father,  Not  Waiting) . 

Destroy  Process 

If  the  specified  process  is  a  son  of  the  calling  process  in 
the  Stop  State  (Stopped  By  Father) ,  then  the  process  and  all  its 
descendants  are  destroyed.  When  a  process  is  destroyed,  its 
resources  are  added  to  those  of  its  father.  Connections  to  the 
ports  of  the  destroyed  process  are  replaced  by  connections  to 
dummy  ports,  and  connections  to  mailboxes  owned  by  the  process 
are  replaced  by  connections  to  dummy  mailboxes. 

Start  Process 

This  primitive  is  issued  by  a  process  to  start  its  son. 
The  specified  process  must  be  in  the  Stop  State  (Stopped  By 
Father) .  All  descendants  of  the  son  process  which  were 
previously  given  the  Stop  State  (Stopped  By  Ancestor)  by  the 
father  process  are  also  started.  All  the  descendants  of  the 
named  process  are  started  "simultaneously"  so  that  a  father  does 
not  unexpectedly  find  a  stopped  son  or  vice  versa.  All 
processes  which  are  started  with  a  Wait  State  of  (Waiting  With 
Message  Available)  will  receive  the  available  message  and  go 
into  the  state  (Not  Stopped,  Not  Waiting) . 

Stop  Process 

This  primitive  is  issued  by  a  father  to  cause  one  of  its 
sons  to  stop  executing.  The  son  goes  into  the  Stop  State 
(Stopped  By  Father),  and  all  of  that  son's  descendants  which 
were  in  the  Stop  State  (Not  Stopped)  go  into  the  Stop  State 
(Stopped  By  Ancestor) .  (One  use  of  this  primitive  is  when  a 
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father  wants  to  stop  a  son  so  that  the  son’s  program  can  be 
rolled  out  of  core. ) 

Inspect  Process 

A  father  may  get  a  copy  of  a  son’s  Process  Descriptor  by 
invoking  this  primitive. 

Modify  Process 

This  primitive  allows  a  process  to  alter  the  general 
purpose  registers,  the  floating  point  registers,  the  program 
status  word  instruction  address,  and  the  trap  mask,  in  either 
its  own  or  a  son's  Process  Descriptor.  It  is  expected  that  this 
primitive  will  be  used  by  processes  which  are  starting  sons  or 
which  are  in  trap  management.  If  a  son  is  to  be  modified,  the 
son  must  be  in  the  Stop  State  (Stopped  By  Father).  When  a  son 
p rocess  is  modified,  its  Wait  State  is  always  set  to  (Not 
Waiting) . 

3.5.2  Synchr oniza tig n_and_ Mess age_ Pass ing  Processes  have  two 
types  of  ports:  input  ports  and  output  pgr t s^  Each  mailbox  is 
connected  to  one  input  port  and  to  one  output  port.  A  message 
sent  through  an  output  port  is  called  a  guery;  and  a  message  sent 
through  an  input  port  is  called  a  peply^  The  following  five 
primitives  are  provides  by  the  Kernel  to  facilitate  process 
synchronization  and  message  passing: 

( 1 )  Send; 

(2)  Receive; 

(3)  Connect; 

(4)  Create  Mailbox; 

(5)  Destroy  Mailbox. 


Send 

This  primitive  is  used  for  sending  one  message  through  a 
specified  port.  The  mailbox  connected  to  the  specified  input  or 
output  port  is  checked  for  the  availability  of  a  slot  in  the 
state  (Waiting  For  Query/Reply) ;  if  any  are  present,  then  the 
message  is  copied  into  the  slot,  which  is  then  marked  as  being 
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in  the  state  (Containing  A  Query/Reply) .  Should  the  mailbox 
connected  to  the  specified  port  not  contain  an  available  slot, 
then  the  message  is  not  sent,  and  the  calling  process  is  warned. 
The  state  of  the  calling  process  is  not  affected.  notice  that 
sending  a  message  may  unblock  a  process  which  is  waiting  for 
information  through  the  mailbox. 

Receive 

This  primitive  is  used  to  receive  one  message.  For  each  of 
the  input  or  output  ports  specified,  the  mailbox  connected  to 
the  port  is  checked  for  the  availability  of  a  slot  in  the  state 
(Containing  A  Query/Beply) .  If  one  of  the  ports  satisfies  this 
condition,  then  the  message  is  copied  from  this  slot  to  the  area 
supplied  by  the  calling  process.  The  invoking  process  may 
request  that  it  be  blocked  if  no  message  is  available,  or, 
alternately,  that  it  merely  be  informed  that  there  is  no 
message. 

Connect 

This  primitive  allows  a  process  to  connect  a  port  to  a 
mailbox.  The  problems  of  specifying  ports  and  mailboxes  as  well 
as  the  protection  question  have  not  as  yet  been  completely 
explored.  Disconnecting  is  accomplished  by  connecting  to  a 
dummy  port  or  a  dummy  mailbox. 

Create  Mailbox 

A  mailbox  with  specified  characteristics  (slot  size  and 
number  of  slots)  is  created.  The  number  of  mailboxes  that  the 
process  is  allowed  to  create  is  decremented  by  one.  Space  for 
the  Mailbox  Body  is  subtracted  from  the  Buddy  Area  claim  of  the 
process  (see  Section  3.5.5).  When  the  mailbox  is  created,  it  is 
connected  to  two  dummy  ports. 

Destroy  Mailbox 

Invoking  this  primitive  results  in  the  destruction  of  the 
specified  mailbox  provided  that  it  is  owned  by  the  calling 
process.  If  the  mailbox  is  not  connected  to  two  dummy  ports,  it 
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is  replaced  by  a  dummy  mailbox.  The  number  of  mailboxes  that 
the  process  is  allowed  to  create  is  incremented  by  one.  The 
space  occupied  by  the  Mailbox  Body  is  added  to  the  Buddy  Area 
claim  of  the  process  (see  Section  3.5.5). 

3.5.3  Trap  Management  There  is  only  one  primitive  which  is 
directly  related  to  trap  management,  namely  Set  Trap. 

Set  Trap 

This  primitive  specifies  a  procedure  which  is  to  receive 
control  when  an  expected  exceptional  condition  arises.  A  trap 
mask  is  also  specified,  indicating  which  exceptional  conditions 
are  now  expected,  and  a  trap  save  area  address  is  specified.  On 
a  trap,  the  user  trap  handler  is  invoked  and  is  provided  with  a 
parameter  which  is  a  pointer  to  the  trap  save  area.  The  trap 
save  area  will  contain  the  general  purpose  and  floating  point 
registers,  the  program  status  word,  and  the  trap  mask  as  they 
existed  at  the  time  of  the  trap.  The  Kernel  also  resets  the 
trap  mask  to  null  before  passing  control  to  the  user  trap 
handler,  thus  eliminating  the  possibility  of  recursive  traps. 
The  trap  mask  may  be  restored  by  the  user  trap  handler  through 
the  invocation  of  Modify  Process  or  Set  Trap. 

If  a  trap  occurs  which  is  not  specified  in  the  trap  mask, 
the  trapped  process  is  placed  in  the  state  (Stopped  By  Father, 
Not  Waiting)  and  the  father  of  the  process  is  notified  of  the 
t rap. ' 

3.5.4  Capability _ Management  Capabilities  are  the  general- 

purpose  locks  and  keys  of  the  SUE  system.  One  of  the  major 
design  goals  of  the  system  is  that  it  must  be  extensible,  and 
inasmuch  as  we  can  not  define  the  universal  resource  set,  we 
must  allow  processes  to  define  arbitrary  resources  and  then 
protect  them  and  account  for  them.  Facilities  for  manipulating 
capabilities  are  not  yet  completely  specified,  tut  they  will 
include  primitives  giving  processes  the  ability  to  create, 
inspect,  modify,  and  pass  capabilities.  The  following 
primitives  have  been  designed  so  far: 
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(1)  Create  Capability; 

(2)  Inspect  Capability; 

(3)  Modify  Capability; 

(4)  Send  Capability; 

(5)  Receive  Capability. 

Create  Capability 

This  primitive  builds  a  capability  according  to  the 
specifications  provided  by  the  process  and  inserts  it  in  the 
specified  capability  slot  in  the  Capability  List  of  that 
process. 

Inspect  Capability 

This  primitive  locates  the  specified  capability  in  the 
Capability  List  of  the  invoking  process  and  places  a  copy  of  it 
in  the  space  provided  by  the  invoking  process. 


Modify  Capability 

The  type  and  attributes  of  the  capability  in  the  given 
capability  slot  of  the  calling  process  are  modified  according  to 
the  description. 

Send  Capability 

This  primitive  is  similar  to  Send,  but  is  used  to  send  a 
capability.  The  contents  of  the  specified  capability  slot  in 
the  Capability  List  of  the  sending  process  are  placed  in  a 
mailbox. 


Receive  Capability 

This  primitive  is  similar  to  Receive,  but  is 
receive  a  capability.  The  capability  is  fetched 
mailbox  and  placed  in  the  specified  capability  slot 
receiver’s  Capability  List. 


used  to 
from  the 
of  the 


3.5.5  Memory  Management  At  the  Kernel  level  in  the  SUE  system, 
we  can  differentiate  between  processes  which  "own”  core  and 
those  which  do  not.  Processes  which  own  core  are  able  to  manage 
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exactly  one  contiguous  core  block,  which  is  a  multiple  of  2K 
bytes.  A  process  which  owns  core  may  manage  it  as  it  wishes 
except  for  its  System  Area  which  the  process  may  request  that 
the  Kernel  manage. 

The  following  three  primitives  can  be  used  by  processes  for 
memory  management: 

(1)  Set  Process  Key; 

(2)  Set  Storage  Key; 

(3)  Create  System  Area. 

Set  Process  Key 

The  key  field  in  the  program  status  word  is  set  to  the  key 
provided.  The  key  must  be  one  of  the  storage  keys  owned  by  the 
invoking  process. 

Set  Storage  Key 

The  key  of  the  specified  2K  block  is  set  to  the  storage  key 
provided.  The  process  must  either  own  the  block  or  have  a 
memory  capability  for  it.  Any  key  may  be  specified. 

Although  the  first  implementation  of  the  Kernel  will  only 
support  the  sixteen  physical  keys  of  the  System/360,  we  expect 
that  successive  implementations  will  support  a  larger  number  of 
logical  keys  which  will  then  be  dynamically  mapped  onto  the 
physical  ones,  as  processes  are  activated. 

Create  System  Area 

The  specified  area  is  placed  in  a  special  memory  key  so 
that  it  cannot  be  accessed  by  any  process.  The  System  Area  is 
preform at ted  when  it  is  alloca  ted ,  according  to  the 
specification  provided  by  the  requesting  process.  It  is  split 
into  two  sections,  the  Fixed  Area  and  the  Buddy  Areax  each  a 
multiple  of  2K  bytes.  The  Fixed  Area  contains  Process 
Descriptors  and  Mailbox  Headers.  The  number  of  each  of  these 
structures  is  defined  and  fixed  when  the  System  Area  is  created. 
The  Buddy  Area,  which  is  managed  with  the  buddy  system 
algorithms  popularized  by  Knuth  [  1968  ]  and  others,  will  contain 
Port  Descriptors,  Capability  Lists,  and  Mailbox  Bodies  (message 
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areas) .  The  Buddy  Area  is  managed  dynamically  by  the  Kernel. 
The  Kernel  maintains  a  System  Area  Descriptor  in  each  System 
Area,  which  records  the  usage  of  each  type  of  structure  in  the 


System  Area. 

3.6  A  Closer  Look 

at, Kernel  Data  Structures 

In  this  section  we  will  present  detailed  descriptions  of 
the  SUE  Process  Descriptors,  Port  Descriptors,  mailboxes. 


capabilities,  and 

System  Area  Descriptors. 

3.6.1  The  Process, 

Descriptor  T^e  Process  Descriptor  is  the  main 

Kernel  data  structure.  It  identifies  a  process,  and  defines  the 
state,  resources,  and  capabilities  of  that  process. 

The  Process  Descriptor  contains  the  following  entries: 


Identification : 

name 

State: 

program  status  word 

general  purpose  registers 

floating  point  registers 

data  stack  address 

Stop  State 

Wait  State 

Trap  information: 

trap  mask 

trap  handler  address 

trap  save  area  address 

Family  links: 

pointer  to  father's  Process  Descriptor 
pointer  to  next  brother’s  Process  Descriptor 
pointer  to  first  son's  Process  Descriptor 

Resources: 

created  System  Area  base  address 

Owned  Area  base  address 

Owned  Area  upper  bound 

allowed  primitives  mask 

allowed  memory  keys 

pointer  to  inherited  System  Area  Descriptor 

pointer  to  Port  Descriptor 

pointer  to  first  Mailbox  Header 

pointer  to  Capability  List 

buddy  claim 
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port  claim 

mailbox  claim 

Process  Descriptor  claim 

Queueing  links:  pointer  to  Process  Descriptor  of 

next  process 

pointer  to  Process  Descriptor  of 
previous  process 


3.6.2  The_Port_ Descriptor  The  Port  Des 
f ields: 

pointer  to  Message  Area 
array  ((1  to  Humber  Of  Ports))  of 
where  Port  is  defined  as: 

Wait  Flag 

Input  Output  Flag 

pointer  to  Mailbox 

The  Wait  Flag  is  "on"  in  a  Port  if 
the  port  is  waiting  on  it.  If  the  p 
mailbox,  the  "pointer  to  Mailbox"  is  nu 
the  address  of  the  Mailbox  Header  to  w 
a  process  invokes  the  Receive  primiti 
available,  and  the  invoking  process  h 
wait  for  the  message,  then  "pointer  to 
indicate  where  the  message  is  to  be  pla 

3.6.3  Mailboxes  In  the  SUE  system,  mail 
sections;  the  Mailbox  Header  and  the  M 
Header  defines  the  state  of  each  slot  i 
is  also  used  to  locate  the  input 
messages  which  pass  through  it.  The  Mja 
length,  and  resides  in  the  Fixed 


lo  wi 

ng  inf or 

mati 

on 

• 

• 

poi 

n  ter 

to 

owni 

ng 

P 

roce 

poi 

nter 

to 

next 

m 

ai 

lbox 

poi 

nter 

to 

Mail 

bo 

X 

Body 

poi 

nter 

to 

inpu 

t 

po 

rt 

poi 

nter 

to 

ou  tp 

ut 

P 

ort 

criptor  has  the  following 


Port 


the  process  which  owns 
ort  is  not  connected  to  a 


11 

r 

ot 

her 

w  is 

e 

it  contains 

hi 

ch 

i 

t  i 

s  c 

on 

nected . 

If 

ve 

t 

a 

nd 

no 

message 

is 

as 

i 

nd 

ica 

ted 

t 

hat  it 

must 

Me 

ss 

ag 

e  A 

rea 

ii 

is  set 

to 

ce 

d 

wh 

en 

it 

ar 

rives. 

bo 

xe 

s 

are 

sp 

li 

t  into 

two 

ai 

lb 

ox 

Bo 

uy. 

The  Mailbox 

n 

th 

e 

Mai 

Ibo 

X 

Body . 

It 

a 

nd 

o 

utp 

ut 

po 

rts  for 

the 

il 

bo 

X 

Hea 

der 

i 

£  Of  f 

i  xed 

Ar 

ea 

• 

I 

t 

CO 

ntains 

the 

35 


number  of  first  slot  waiting  for  query 
number  of  first  slot  containing  query 
number  of  first  slot  waiting  for  reply 
number  of  first  slot  containing  reply 
message  length 
number  of  slots 

The  Mailbox  Body  consists  of  a  number  of  slots.  Each  slot 
contains  control  information  which  indicates  whether  the  slot  is 
empty,  contains  a  query,  contains  a  capability,  or  contains  a 
dummy  message.  The  Mailbox  Body  resides  in  the  Buddy  Area. 

3.6.4  Capabilities  Capabilities  are  the  general-purpose  locks 
and  keys  of  the  SUE  system.  We  presently  have  well-formed 
concepts  of  what  they  are  and  what  we  want  them  to  do,  but  as 
yet  we  have  only  rough  ideas  as  to  what  they  look  like  and  how 
they  are  manipulated. 

We  know  that  capabilities  contain  an  identification  field, 
some  attributes  and  an  optional  numeric  field.  The  attributes 
might  indicate  that  the  capability  is  numeric  or  Boolean,  or 
whether  or  not  it  may  be  passed  or  copied.  For  example,  the 
capability  which  allows  a  process  to  do  disk  I/O  operations 
would  contain  an  identification  indicating  that  it  is  for  disk 
I/O,  that  it  is  numeric,  may  not  be  copied,  and  it  is  "good”  for 
50  disk  operations. 

3.6.5  The  System  Area  Descriptor  A  System  Area  Descriptor  is 
kept  at  the  beginning  of  each  System  area.  It  contains 
information  describing  the  contents  of  the  System  Area  in  which 
it  resides.  Its  format  is  as  follows: 

free  area  root  list 
pointer  to  Buddy  Area 
size  of  Buddy  Area 

number  of  bytes  available  in  Buddy  Area 
total  number  of  Process  Descriptors 
number  of  Process  Descriptors  available 
pointer  to  first  unallocated  Process  Descriptor 
total  number  of  Port  Descriptors 


number  of  Port  Descriptors  available 
pointer  to  first  unallocated  Port  Descriptor 
total  number  of  Mailboxes  Headers 
number  of  Mailbox  Headers  available 
pointer  to  first  unallocated  Mailbox  Header. 

3.7  Conclus ion_and_Su mmary 

In  the  preceding  sections  we  have  described  the  Kernel  of 
the  SUE  system.  The  Kernel  is  a  body  of  code  which  implements 
processes  and  provides  them  with  the  following  facilities: 

(1)  clocking  services; 

(2)  access  to  channels; 

(3)  trap  management; 

(4)  memory  management; 

(5)  capability  management; 

(6)  synchronization  primitives. 

It  also  manages  asynchronous  interrupts  and  converts  them  into  a 
convenient  form  for  processes.  This  last  point  is  of  the  utmost 
importance,  because  it  allows  processes  to  proceed  as  if  each 
had  its  own  processor. 

We  have  designed  the  primitives  in  our  system  such  that 
they  provide  a  good  set  of  commonly  required  operations.  There 
was  no  attempt  to  define  a  set  of  completely  independent 
primitive  operations  which  could  not  be  derived  from  any  other 
available  functions.  The  primitives  not  only  provide  commonly 
required  services ,  but  also  implement  a  large  part  of  the  SUE 
system’s  protection  mechanism. 


4.  I/O  SYSTEM 


4.1  Structure 

The  I/O  hardware  of  the  System/360  series  of  computers 
consists  of  a  four-level  hierarchy: 

(1)  channels; 

(2)  subchannels; 

(3)  control  units; 

(4)  devices. 

There  are  two  types  of  System/360  channels:  selector 
channels  and  multiplexor  channels. 

A  selector  channel  has  one  subchannel,  and  is  capable  of 
supporting  data  transfer  to  only  one  device  at  a  time.  A 
multiplexor  channel  has  many  subchannels,  and  is  capable  of 
accepting  several  requests  concurrently. 

All  channels  present  a  standard  interface  to  control  units. 
A  control  unit  acts  as  an  interpreter  between  a  channel 
interface  and  a  device.  A  device  is  typically  electro¬ 
mechanical.  The  structure  of  interconnection  of  channels, 

control  units,  and  devices  is  normally  a  tree,  but  various 

hardware  options  permit  the  structure  to  take  the  form  of  an 

acyclic  directed  graph. 

The  System/360  Start  I/O  instruction  indicates  (indirectly) 
the  unit  address,  the  memory  protection  key  for  the  I/O 
operation,  and  the  location  in  processor  storage  of  a  stored 
program  (in  the  form  of  channel  command  words]_  to  be  used  to 
govern  the  I/O  operation. 

When  an  I/O  interrupt  is  taken  by  the  CPU,  information  is 
stored  (in  the  channel  status  word)  which  indicates  the  channel 
status,  the  control  unit  status,  the  device  status,  and  how  much 
of  the  stored  program  has  been  executed.  If  an  error  has 
occurred,  additional  information  concerning  the  device  and 
control  unit  status  is  available  if  a  Sense  command  is  issued  to 
the  device.  This  information  may  be  lost  if  the  channel  is 
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ana bled  for  interrupts  before  the  Sense  is  issued. 

In  the  SUE  system,  processes  communicate  with  each  other  by 
passing  messages  through  ports  into  mailboxes.  One  of  the 
functions  of  the  Kernel  is  to  convert  the  interaction  between 
the  CPU  and  the  I/O  hardware  into  the  standard  message  format. 
This  Kernel  I/O  Manager  effectively  has  as  many  ports  on  it  as 

there  are  channels  in  the  hardware.  (It  does  not  in  fact  have 

ports,  because  the  Kernel  is  not  a  process.)  Each  of  these 
ports  reacts  in  exactly  the  same  way  as  its  associated  channel, 
except  that  requests  are  sent  to  it  in  the  form  of  a  message, 

and  responses  are  received  in  the  same  manner.  We  call  this 

software-enhanced  channel  a  logical  channel^ 

The  message-passing  mechanism  is  used  throughout  the  I/O 
System.  Each  element  of  the  hardware  is  managed  by  a  process, 
which  is  synchronized  with  it.  The  com  mu  nica  t  ion  .paths  between 
these  managing  processes  are  an  internal  image  of  the  hardware 
I/O  connections.  The  Kernel  I/O  Manager  is  the  innermost  level 
of  this  communication  hierarchy.  Its  functions  are  to  issue  the 
I/O  instructions,  and  to  handle  the  resulting  I/O  interrupts. 
The  next  level  of  the  I/O  hierarchy  consists  of  the  Channel 
These  managers  use  the  logical  channels  provided  by 
the  Kernel  to  implement  logical  control  units,  (There  are  no 
subchannel  managers.  The  existence  of  multiple  subchannels  is 
reflected  in  differences  in  the  design  of  the  selector  and 
multiplexor  Channel  Managers.)  The  Control  Unit  Managers  use 
logical  control  units  to  implement  logical  devices.  The  Device 
Managers  provide  logical  printers^  etc.,  as  appropriate. 

This  design  provides  three  major  advantages.  first,  the 
software  is  organized  such  that  asynchronous  activity  in  the 
hardware  is  managed  as  though  it  were  synchronous.  This  makes 
design  and  implementation  much  easier  conceptually.  Second, 
special  conditions  such  as  channel  errors  are  invisible  at  outer 
levels.  That  is,  problems  are  resolved  by  the  level  which  is 
best  equipped  to  handle  them,  and  are  transparent  to  other 
levels.  Third,  all  device-dependent  activity  is  localized  at 
the  outermost  level  of  the  hierarchy. 
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4.2  The  Kernel  I/O  Manager 

The  Kernel  I/O  Manager  is  responsible  for  issuing  the 
System/360  I/O  instructions,  in  accordance  with  the  requests  of 
the  Channel  Managers,  and  returning  the  results  of  the 
operations  in  a  message.  Communication  between  the  Kernel  I/O 
Manager  and  the  Channel  Managers  will  be  by  means  of  special 
forms  of  the  Send  and  Receive  primitives. 

&  Channel  Manager  will  request  that  I/O  be  started  by 
sending  a  query  (see  the  definition  of  query  and  reply  in 
Section  3.5.2).  The  Kernel  I/O  Manager  will  respond  with  an 
indication  of  the  success  or  failure  of  the  operation,  together 
with  the  channel  status  word  (if  any)  ,  and  the  sense  information 
(if  unit  check  is  indicated  in  the  channel  status  word) ,  in  the 
fora  of  a  reply.  Replies  of  the  same  form  will  also  be 
assembled  when  interrupts  occur,  and  placed  in  mailbox  slots 
provided  by  the  Channel  Managers.  (See  the  discussion  of 
unexpected  interrupts  in  Section  4.3.3.)  The  size  of  returned 
messages  is  egual  to  the  size  required  to  indicate  success  or 
failure,  plus  room  for  the  channel  status  word  and  sense 
information. 

4.3  Channel  Managers 

There  are  two  types  of  Channel  Managers:  one  for 
multiplexor  channels  and  one  for  selector  channels.  The 
differences  between  the  two  types  of  managers  stem  from  the  fact 
that  the  multiplexor  Channel  Manager  must  support  concurrent  I/O 
operations  while  the  logic  for  the  selector  Channel  Manager  is 
based  on  sequential  I/O  operations. 

Both  Channel  Managers  have  to  deal  with  three  types  of 
special  conditions,  namely,  channel  errors,  control  unit  busy, 
and  unexpected  interrupts. 

4.3.1  Channel _ Errors  We  hope  to  deal  with  channel  error 

conditions  by  using  the  algorithms  specified  in  the  IBM  nI/0 
Supervisor  Program  Logic  Manual”  [1970].  To  date  there  has  been 
no  detailed  investigation  into  this  area. 
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4.3.2  Control  Unit  Busy  If  a  Channel  Manager  issues  a  control 
command  for  a  Control  Unit  Manager,  channel  end  may  be  issued 
while  the  associated  control  unit  is  still  active.  If  a  later 
command  issued  by  the  Channel  Manager  is  for  a  device  on  the 
same  control  unit,  ana  that  control  unit  is  still  active,  the 
control  unit  responds  with  a  status  of  control  unit  busy.  This 
condition  is  expected  to  be  very  rare,  but  our  design  must  take 
account  of  the  fact  that  it  does  occur.  In  this  case  the 
Channel  Manager  is  left  holding  a  request  for  some  undetermined 
length  of  time.  It  cannot  wait  for  the  corresponding  control 
unit  end  because  the  hardware  does  not  guarantee  that  it  will 
aver  come.  A  proposed  solution  is  that  the  request  be  marked  as 
having  given  rise  to  the  control  unit  busy  condition,  and  that 
the  port  connected  to  the  associated  Control  Unit  Manager  be 
removed  from  the  list  of  ports  currently  being  serviced.  When 
the  required  control  unit  end  comes,  the  request  which  has  been 
held  pending  is  re-issued,  and  the  port  is  re-inserted  in  the 
list  of  ports  being  serviced. 

This  solution  is  proposed  for  two  reasons.  First,  it  means 
that  for  all  levels  outside  the  Channel  Managers,  a  request  once 
made  will  always  receive  a  "comple ted"  response  at  some  later 
time  {unless  the  hardware  fails  unrecoverable),  and  the  response 
"it's  busy  now,  but  try  later"  need  never  be  given.  Second,  it 
avoids  the  situation  where  a  Control  Unit  Manager  issues  several 
requests,  all  of  which  tail  (r ecoverabl y)  because  the  control 
unit  is  nusy. 

4.3.3  U nexpec ted_ In terr upts  Because  of  device  malfunction  or 
human  intervention,  an  interrupt  may  be  presented  to  a  Channel 
Manager  for  a  device  for  which  there  is  no  pending  request, 
i.e.,  there  is  no  mailbox  slot  available  for  a  message  to  that 
device's  Control  Unit  Manager.  An  interrupt  will  also  be 
presented  if  the  program  controlled  interrupt  flag  is 
encountered  in  a  channel  command  being  executed  by  a  channel. 
An  uH£2££c:t§d  interrupt  is  said  to  occur  when  a  channel  status 
word  is  stored  for  a  device  for  which  the  appropriate  Channel 
Manager  does  not  currently  have  a  mailbox  slot  available  for 
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communication  with  that  device’s  associated  Control  Unit 
Hanager.  The  channel  status  word  will  indicate  device  end, 
attention,  or  program  controlled  interrupt.  In  each  case,  the 
Channel  Hanager  will  flag  the  port  that  carries  messages  from 
that  Control  Unit  Manager.  When  the  associated  Control  Unit 
Manager  does  sent  a  request  the  reguest  is  sent  back 
(unexecuted)  with  an  indication  of  the  nature  of  the  unexpected 
interrupt.  The  flag  is  then  removed  from  the  port. 

In  order  to  ensure  that  interrupts,  once  recognized  by  the 
physical  channel,  are  not  lost,  the  Kernel  I/O  Manager  will  have 
the  capability  of  inhibiting  interrupts  from  a  channel  when  the 
Channel  Manager’s  last  slot  is  filled.  This  forces  interrupts 
to  be  held  pending  in  the  channel  hardware  until  the  Channel 
Manager  sends  a  slot  up  to  the  Kernel  I/O  Manager.  It  is  known 
that  a  single  Start  I/O  instruction  can  result  in  up  to  three 
interrupts,  and  also  that  unexpected  interrupts  will  happen. 
Because  of  the  unpredictability  of  the  number  and  rate  of 
interrupts,  and  in  order  to  minimize  the  amount  of  time  that  any 
channel  is  inhibited  for  interrupts,  the  Channel  Manager  will 
send  some  empty  slots  to  the  Kernel  I/O  Manager.  There  has  been 
no  attempt  at  this  time  to  determine  the  optimal  number  of 
slots,  but  it  seems  apparent  that  the  number  will  be  a  function 
of  the  average  rate  of  unexpected  interrupts  and  the  cost  of 
mailbox  slots. 

4.4  Control  Unit  Managers  and  the  Volume  Manager 

There  is  a  Control  Unit  Manager  for  each  physical  control 
unit  that  services  several  devices.  Where  the  control  unit  and 
device  are  indistinguishable,  there  will  only  be  one  managing 
process.  Each  Control  Unit  Manager  has  two  functions  to 
perform,  namely,  handling  control  information  for  the  Volume 
Manager  and  providing  a  path  for  I/O  requests  from  the  Device 
Managers  to  the  Channel  Manager. 

The  Volume  Manager  is  responsible  for  arranging  with  the 
Archconsole  operator  (or  some  other  operator,  perhaps  in  the  I/O 
room)  for  the  mounting  of  volumes,  and  for  informing  the  Control 
Unit  Manager  of  the  correspondence  between  the  logical  volume 
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and  the  physical  device  address. 

A  physical  device  address  is  not  an  intrinsic  property  of  a 
Device  Manager  when  that  device  supports  discountable  volumes. 
In  this  case,  device  addresses  are  associated  with  ports  on  the 
Control  Unit  Manager  rather  than  with  the  Device  Managers 
themselves . 

The  Volume  Manager  specifies  to  the  Control  Unit  Manager 
that  requests  that  it  receives  through  a  certain  port  are 
destined  for  a  particular  device  address.  This  means  that 
moving  a  volume  from  one  drive  to  another  (for  operator 
convenience  or  because  of  device  failure)  is  a  matter  for 
negotiation  between  the  Volume  Manager  and  the  operator  (via  the 
Archconsole).  This  organization  makes  it  possible  to  support 
multiple  (and  incompatible)  file  systems,  and  to  connect  and 
disconnect  special  Device  Managers. 

The  control  path  of  a  Control  Unit  Manager  is  used  in  one 
direction  to  provide  the  Volume  Manager  with  information 
concerning  physical  device  failure  and  unexpected  interrupts, 
and  in  the  other  direction  to  inform  the  Control  Unit  Manager  of 
the  mapping  to  be  used  between  Device  Managers  and  physical 
device  addresses.  This  control  information  can  also  be  used  to 
implement  automatic  recognition  of  newly  mounted  volumes. 


4.5  Dev ice_ Managers 

The  Device  Managers  will  be  the  most  com 
I/O  System,  due  to  the  structure  of  the  S 
Basically,  the  Device  Managers  will  select 
requesting  processes,  convert  them  to  a 
format,  and  pass  them  up  to  the  Control 
execution.  It  is  of  the  utmost  importa 
Managers  present  a  clean  interface  to  the  use 

The  Device  Managers  are  responsible 
dependent  features,  device-level  error 
procedures ,  and  request  selection  strategies, 
hoped  that  (for  example)  all  2314  module  dri 
same  in  our  system,  there  is  no  reason  to  pro 
selecting  by  priority  while  another  uses  FIFO 
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Device-level  error  recovery  for  disks  will  be  core 
resident.  Recovery  modules  for  other  devices  will  be  kept  on 
disk,  and  the  Basic  File  System  will  be  used  to  load  them  as 
required.  (See  discussion  of  the  structural  relationship  of  the 
Disk  I/O  System,  the  Basic  File  System,  and  the  Peripheral  I/O 
System,  in  Section  2.4.)  We  intend  to  use  the  recovery 
procedures  specified  in  the  IBM  ”1/0  Supervisor  Program  Logic 
Manual"  [  1970 ]. 

4.6  Device  Allocation 

The  Device  Allocator  is  the  father  of  the  I/O  System.  It 
is  responsible  for  satisfying  all  requests  from  processes  for 
logical  I/O  devices.  If  the  device  exists  and  is  idle,  the 
Device  Allocator  will  arrange  to  connect  the  requestor's  mailbox 
to  the  port  of  the  appropriate  Device  Manager.  In  addition,  the 
Device  Allocator  responds  to  commands  from  the  Ultimate  Ancestor 
that  certain  devices  are  to  be  logically  connected  or 
disconnected  from  the  system.  (The  source  of  this  authority  is, 
of  course,  the  Archconsole  operator.)  If  an  allocated  device  is 
to  be  logically  disconnected,  the  current  user,  if  any,  will  be 
informed. 

Device  requests  will  be  made  in  one  of  four  forms: 

(1)  device  address  only; 

(2)  device  type  only; 

(3)  device  address  and  volume; 

(4)  device  type  and  volume. 

(Forms  (3)  and  (4)  apply  only  to  devices  having  dismountable 
volumes. ) 

If  a  request  is  made  for  a  specific  unit,  that  unit  will  be 
allocated  if  it  is  available.  If  it  is  not  available, 
information  will  be  assembled  concerning  the  reason  for  the 
conflict,  and  sent  to  the  Ultimate  Ancestor,  with  the  request 
that  it  ask  the  Archconsole  operator  to  resolve  the  conflict 
(typically  by  cancelling  either  the  requesting  or  interfering 
process) . 

If  a  device  type  is  specified  (e.g.,  printer,  disk)  then 
the  request  is  honoured  by  allocating  any  available  physical 
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device  of  that  type. 

If  a  volume  is  requested  on  a  particular  unit  address,  or 
on  a  device  type,  then  the  Volume  Manager  must  be  consulted.  If 
the  volume  is  mounted,  or  the  Volume  Manager  can  arrange  for  it 
to  be  mounted,  then  the  device  is  allocated  as  requested. 
Otherwise,  the  Device  Allocator  refuses  the  request. 
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5.  BASIC  FILE  SYSTEM 

5.1  General  Considerations 

This  section  outlines  the  operation  of  the  Basic  File 
System  in  the  SUE  Nucleus.  The  Basic  File  System  implements 
only  Disk  Files.  User-oriented  and/or  subsystem  file  systems 
will  be  outside  the  Nucleus. 

The  goals  for  the  Basic  File  System  are: 

(1)  A  complete  set  of  instructions  which  can  be  used  to 
implement  more  user-oriented  commands. 

(2)  A  structural  design  which  will  allow  the  introduction 
of  new  processes  to  accommodate  extra  facilities,  e.g., 
different  sponsor  directories  and  space  allocation 
schemes. 

(3)  Adequate  facilities  for  the  development  of  the  rest  of 
the  SUE  Nucleus. 

There  are  two  rigid  assumptions  made: 

(1)  ail  files  consist  of  an  integer  number  of  fixed-size 
blocks. 

(2)  Files  are  not  allowed  to  grow. 

The  following  assumptions  concern  the  first  implementation  and 
can  change  later  on. 

(1)  Space  is  allocated  using  a  single  allocation  scheme. 
We  propose  the  buddy  system. 

(2)  The  file  system  will  trust  that  capabilities  issued  by 
the  system  are  valid. 

(3)  The  size  of  fixed-size  blocks  for  memory  allocation  is 
2K  bytes. 

The  file  system  will  utilize  the  capability  concept  in 
order  to  monitor  access  to  files.  Capabilities  fall  into  two 
main  categories: 

(1)  Authorization  capabilities  specifying  access  attributes 
to  particular  files,  volumes,  etc. 

(2)  Financial  capabilities  specifying  authorization  from  a 


Sponsor  to  issue  a  specific  number  of  a  particular 
command.  Financial  capabilities  are  used  mainly  for 
accounting  and  billing  purposes. 


5.2  Facilities 

Eleven  commands  are  implemented  by  the  Basic  File  System: 

(1)  Bequest ; 

(2)  Release ; 

(3)  Attach; 

(4)  Detach; 

(5)  Create  ; 

(6)  Delete ; 

(7)  Open; 

(8)  Close; 

(9)  Read; 

(10)  Write ; 

(11)  Switch. 

Request  (Volume  flame.  Capability) 

The  process  issuing  the  command  (henceforth  called  the 
process)  asks  for  the  allocation  of  an  extra  volume  named 
Volume  Name.  The  Capability  indicated  is  a  financial  capability 
for  requesting  a  volume. 

Release  (Volume  Name) 

The  process  wants  to  release  a  volume  it  owns  for  other 

u  ses. 

Attach  (Volume  Name,  Capabilities) 

The  process  wants  to  mount  a  volume  it  can  use  on  a  logical 
drive.  The  capabilities  are  for  the  use  of  the  volume 
Volume  Name,  and  for  the  ownership  of  a  logical  drive. 

Detach  (Volume  Name) 

The  process  wants  to  dismount  the  volume  Volume  Name  from 
the  logical  drive  it  was  mounted  on  and  get  back  the  logical 
drive. 
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Create  (File  Name,  Size,  Volume  Name,  Capabilities) 

The  process  wants  to  create  a  file  File  Name.  If  a 
Volume  Name  is  specified  it  wants  the  file  to  be  on  a  particular 
volume.  If  it  is  not  given,  the  File  System  will  place  the  File 
on  a  public  volume.  The  capabilities  specified  are  fcr  creating 
files  (financial) ,  and  for  using  the  specified  volume  (if 
specified) . 

Delete  (File  Name,  Capability) 

The  process  wants  to  delete  the  file  File  Name.  The 
capability  specified  is  for  ownership  of  the  file. 

Open  (File  Name,  Capabilities) 

The  process  wants  to  open  (link  to)  a  file  File  Name.  The 
capabilities  specified  are  for  opening  files  (financial)  and  for 
opening  the  particular  file. 

Close  (File  Name) 

The  process  wants  to  close  (disconnect  from)  the  file 
File  Name. 

Read  (File  Name,  File  Block,  Count,  Storage  Address, 
Capabilities) 

The  process  wants  to  read  from  the  file  File  Name,  starting 
from  block  File  Block,  proceeding  for  Count  blocks;  and  to 
deposit  the  data  in  processor  storage  beginning  at  the  location 
Storage  Address,  which  must  indicate  a  2K  byte  boundary.  The 
capabilities  specified  are  for  issuing  read  commands  (financial) 
and  for  reading  File  Name. 


Write  (File  Name,  File  Block,  Count,  Storage  Address, 
Capabilities) 

The  process  wants  to  write  into  the  file  File  Name, 
starting  from  block  File  Block,  proceeding  for  Count  blocks; 
taking  the  data  from  processor  storage  beginning  at  the  location 
Storage  Address,  which  must  indicate  a  2K  byte  boundary.  The 
capabilities  specified  are  for  issuing  write 


issuing 


commands 
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(financial)  and  for  writing  on  File  Same. 

Switch  (File  Name,  Capabilities) 

The  process  wants  to  change  the  capability  for  use  of  a 
particular  file.  This  will  not  affect  the  processes  which  have 
the  file  open,  but  subsequently  no  process  will  have  access  to 
the  file  unless  it  produces  the  new  capability.  A  process  can 
change  the  financial  capability  in  the  same  way.  The 
capabilities  presented  are  for  ownership  of  the  file  and/or  for 
creating  files  (financial),  and  the  new  capability. 

Each  command  will  have  many  possible  outcomes.  Consider, 
as  an  example,  the  Create  command  which  has  the  following 
outcomes : 

(1)  The  file  File  Name  has  been  created.  Here  is  the 
capability  for  ownership  of  the  file. 

(2)  Your  financial  capability  is  no  good. 

(3)  The  name  File  Name  is  in  conflict.  Please  change  it. 

(4)  The  capability  you  specify  for  the  volume  is  no  good. 

(5)  Volume  Name  cannot  be  found. 

(6)  Volume  Name  is  not  mounted.  Please  arrange  for  it  to 
be  mounted. 

(7)  Volume  Name  or  the  file  system  is  full.  Your  file 
cannot  be  created. 

(8)  Really  sorry,  but  something  went  drastically  wrong. 

5.3  Organization 

Files  have  corresponding  entries  in  a  Sponsor  Directory. 
At  this  point  there  is  only  one  Sponsor  Directory.  Later  on  a 
tree-structured  Sponsor  Directory  will  be  implemented 
corresponding  to  the  Sponsor  structure.  The  entries  in  the 
Sponsor  Directory  simply  point  to  the  appropriate  entries  in  the 
Plaster  Directory.  We  will  allow  both  sharing  and  the  ability  to 
use  local  names  for  files. 
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For  every  file  there  is  a  unique  entry  in  the  Master 
Directory.  The  entry  will  be  of  the  following  fora: 


unique  identification 
for  the  file 


linked  list  of  opened  files 


capability  for  ownership 

date  of  creation 

linked  list  of  active  users 

t. 

entries 


pointer  to  the  File  X  manager 
capability  for  use 


linking  information 
Volume  Same 


pointer  to  Volume  Table 

cylinder,  track,  record  of  the  beginning 
size  of  file 

Allocator  and  Address  Calculator  pointers 


For  every  successful  execution  of  an  open  command  in  the 
file  system,  a  process  is  created  to  manage  the  read  and  write 
operations  for  the  particular  file.  Pointers  to  the  processes 
are  kept  in  the  Master  Directory  to  ensure  that  the  processes  do 
not  change  the  file  concurrently  with  other  operations  on  the 
file. 

The  File  System  manages  two  sets  of  volumes.  Requla r 
volumes  belong  to  the  File  System  and  are  used  to  allocate  space 
for  regular  files.  Special  volumes  belong  to  other  owners  in 
the  system,  but  are  managed  for  them  by  the  File  System.  A 
Volume  Table  is  kept  containing  the  current  status  of  all 
volumes.  The  entries  contain: 

(1)  Onique  Volume  identifier. 

(2)  Logical  drive  and  capability  if  the  volume  is  mounted. 

Flagged  if  the  volume  is  not  mounted. 

(3)  Count  of  currently  open  files. 

(4)  Identification  of  the  capability  for  ownership. 

(5)  Date  of  creation. 

Note  that  the  entries  are  of  fixed  size. 
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The  Basic  File  System  is  organized  as  a  File  System  Manager 
plus  several  File  Managers,  one  for  each  currently  open  file. 
The  File  System  Manager  consists  of  modules  which  implement  the 
following  functions: 

(1)  Sponsor  Directory; 

(2)  Master  Directory; 

(3)  Accountant  ; 

(4)  Address  Calculation; 

(5)  Volume  Table; 

(6)  Volume  Allocation. 

Figure  5.3-1  is  a  diagram  of  the  relationships  among  the 
File  System  processes,  the  Nucleus  processes,  and  the  User 
processes.  Dotted  lines  indicate  communication  paths.  Solid 
lines  indicate  control  paths. 


Fi3ure_5_.  3- J_Bas  ic_Fi  le 
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6.  BANKER 


6.1  Definitions 

The  Banker  serves  two  primary  functions.  It  verifies  that 
a  certain  Sponsor  is  capable  of  honoring  a  future  charge,  and  it 
places  Transaction  Records  on  disk  storage  for  future  use  by  a 
billing  process. 

A  Unit  of  Work  is  defined  by  each  subsystem,  but  it  might 
typically  consist  of  one  interactive  session,  or  one  batch  job. 

A  Transaction  Record  is  a  concise  encoding  of  the  resources 
used  up  by  a  Unit  of  Work. 

An  Authorization _ Code  is  an  authorization  to  use  the 

facilities  of  a  computer  center.  It  consists  of  a  numeric 
capability  for  the  use  of  a  sum  of  money  (computer  center 
dollars) . 

A  Sponsor  is  a  record  (on  disk)  consisting  of  a  sponsor 
number,  the  current  password  (if  any),  and  a  list  of: 

(1)  one  or  more  sums  of  money  (computer  center  dollars) ; 

(2)  the  one  or  more  subsystems  where  each  sum  of  money  can 
be  spent. 

Example:  A  sponsor  might  wish  to  allow  CC$  1000  for  batch 
computation  and  CC$  50  for  interactive  computation. 

An  Indirect  Sponsor  is  similar  to  a  Sponsor,  except  that 
its  "sums  of  money"  are  instead  pointers  to  the  sums  of  money 
held  by  a  Sponsor.  Certain  restrictions  may  have  to  be  imposed, 
e.g.,  that  the  subsystems  supported  by  an  Indirect  Sponsor  are  a 
subset  of  the  subsystems  supported  by  its  associated  Sponsor,  or 
that  the  subsystems  supported  are  the  same  as  those  supported  by 
one  single  sum  of  money. 

Further  levels  of  sponsorship  will  be  handled  external  to 
the  Nucleus. 
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6.2  0£e ration 

A  subsystem  may  be  started  by  the  Ultimate  Ancestor,  as 
directed  by  the  Archconsole,  or  by  a  Nucleus  Console,  acting 
through  the  Console  System.  At  the  time  of  starting,  a 
subsystem  will  be  given  capabilities  for  quantities  of  those 
resources  which  are  managed  by  the  Kernel  (and/or  Nucleus) ,  and 
the  capabilities  to  use  them. 

Example:  When  the  I/O  System  is  started,  it  will  be  given 
Kernel  resource  capabilities,  including  memory,  CPU  time,  and 
CPU  speed.  The  File  System  will  need  memory,  CPU  tim.e,  CPU 
speed,  and  a  capability  for  I/O.  A  sub-operating  system  will 
need  memory,  CPU  time,  CPU  speed,  disk  I/O  capabilities  (if  it 
will  do  non-File  System  I/O),  and  file  operations  of  the  types 
implemented  in  the  Basic  File  System, 

If  a  subsystem  wishes  to  bill  Sponsors  (other  than  its  own) 
for  services  that  it  will  render,  it  will  establish  a  mailbox 
between  its  Subsystem  Banker  and  the  Nucleus  Banker.  When  a 
subsystem  discovers  a  Unit  of  Work  (typically,  when  a  user  signs 
on  indicating  a  particular  Sponsor,  or  when  a  job  is  initiated 
in  the  batch  processor) ,  the  Subsystem  Banker  will  present  the 
Nucleus  Banker  with  a  Sponsor  number,  and  the  (computed) 
estimated  computer  center  dollar  charge  that  will  result  from 
its  Unit  of  Work.  The  Nucleus  Banker  will  verify  that  the 
designated  Sponsor  is  capable  of  paying  (and  willing  to  pay  the 
requesting  subsystem) ,  and  debit  his  account.  (This  is  similar 
to  certifying  a  cheque.)  Once  the  Unit  of  Work  is  completed, 
the  Subsystem  Banker  will  present  a  credit  slip  and  a 
Transaction  Record.  The  credit  (in  computer  center  dollars) 
will  be  refunded  to  the  Sponsor,  and  the  Transaction  Record  will 
be  recorded  on  disk  for  later  use  by  the  billing  program. 


Note  that  if  subsystems  do 

not 

wish 

to 

ch  eck 

before 

performing  a  service,  they  are  free 

to  do 

so. 

and 

present 

a  bill 

later.  Similarly  subsystems  which 

wish 

to 

do 

no  accounting 

whatsoever,  or  to  account  differently,  are  not  required  to  use 
this  accounting  scheme.  The  only  things  accounted  for  in  this 
case  are  the  Kernel/Nucleus  resources  charged  to  the  Sponsor  of 
the  subsystem  when  it  was  invoked. 
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Note  that  any  Unit  of  Work  will  run  using  the  capabilities 
supplied  to  the  subsystem  when  the  subsystem  was  loaded.  New 
capabilities  are  not  generated  for  the  use  of  the  Unit  of  Work. 
The  cost  of  the  services  used  will  be  billed  later,  so  that  the 
subsystem  can  recover  its  "operating  capital". 
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SYSTEM  LANGUAGE 


7.1  La nquaqe_ Design _Consi.de rat  ions 

The  System  Language  for  Project  SUE  has  been  shaped  by  a 
variety  of  influences:  the  needs  of  the  project  (as  we  perceive 
them),  the  nature  of  the  System/360,  our  experience  with  other 
languages,  and  (by  no  means  least  important)  the  tastes  and 
preferences  of  project  members.  We  have  freely  borrowed  ideas 
and  forms  from  existing  languages  where  they  appealed  to  us.  A 
complete  list  of  credits  is  impossible,  but  our  debt  to  Pascal 
[ Wirth  1971]  is  enourmous  and  obvious;  users  of  BLISS  [ Wulf 
1970],  LSD  [Bergeron  and  Van  Dam  1971],  and  XPL  [ McKeeman  1970] 
will  also  recognize  familiar  ideas.  We  have  tried  to  mold  these 
elements  into  a  coherent  whole,  which  project  members  will  read 
and  write  fluently.  We  started  from  the  following  premises: 

(1)  The  System  Language  must  facilitate  nicely  structured 
programs  and  data.  It  must  be  convenient  to  write 
compact  programs,  whose  control  structure  is  readily 
apparent  and  amenable  to  demonstrations  of  correctness. 
Our  view  of  "nice"  structure  is  that  it  is  essentially 
hierarchical  (refinement  by  subdefinition)  and  includes 
nesting  constructs  such  as  blocks  and  procedures,  and 
certainly  excludes  undisciplined  constructs  such  as 
GO  TO.  Data  structures  must  be  flexible,  powerful,  and 
intuitive.  The  most  pleasing  model  we  have  found  for 
adequate  data  structuring  capabilities  is  the  language 
Pascal . 

(2)  The  System  Language  must  be  readable.  We  include  this 
as  a  separate  requirement  because  programs  in  some 
"powerful"  languages  are  totally  incomprehensible 
except  to  the  person  who  wrote  them.  We  insist  that 
the  language  encourage  clarity  of  expression,  in  its 
constructs,  naming  rules,  comment  facilities,  and 
paragraphing  conventions. 
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(3) 


(4) 


(5) 


(6) 


The  System  language  must  actively  assis 
detection  and  isolation  of  bugs  and  logi 
This  implies  facilities  for  both  corapile-tim 
time  checking,  based  on  redundancy  buil 
language.  All  variables  must  be  declared 
types  of  all  expressions  (including  par 
parametric  procedures,  and  the  results  of 
pointers)  checked  at  compile  time.  Pointers 
have  a  life-time  exceeding  that  of  the  ob 
point  to. 

The  System  Language  must  be  compilable  into 
System/360  code.  This  has  two  aspects:  t 
cannot  be  allowed  "powerful”  constru 
inherently  produce  bad  code,  of  which 
language  programmer  is  unaware;  neither  can 
restrictive  that  the  source-language  pro 
forced  into  circumlocutions  to  express  a 
which  is  "natural"  in  the  machine.  There  i 
to  make  it  "machine-independent",  except  whe 
dependency  conflicts  with  clarity  or  power. 
While  the  programmer  should  not  normally  nee 
about  machine  idiosy nchrasies ,  the  System  La 
permit  him  precise  control  over  both  the  e 
instructions  and  the  allocation  of  s 
registers,  when  he  wishes  it.  An  operating 
concerned  with  the  efficient  exploita 
particular  machine,  and  its  innermost  layer 
machine-dependent  in  peculiar  ways.  There  i 
to  build  into  the  System  Language  a  constr 
"save  floating  point  registers")  which  will 
only  one  place;  neither  do  we  wish  to  have  a 
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(7)  The  System  Language  must  have  an  efficient  compiler. 
We  wish  to  generate  a  complete  system  in  rather  closer 
to  a  minute  than  an  hour;  change  of  a  module  should  not 
require  recompilation  of  unaffected  modules. 
Similarly,  the  output  of  the  compiler  should  not 
require  postprocessing  by  link  editors,  etc.,  and  the 
loader  should  be  simple  and  fast. 

(8)  Implementation  of  the  System  Language  must  not  be  too 
time  consuming.  We  view  it  as  a  means  to  an  end; 
within  the  context  of  Project  SUE  six  man-months  is 
time  well-spent,  but  two  man-years  would  be  an 
excessive  overhead.  In  practice,  this  has  meant 
restricting  our  grammars  to  LALU(1)  [  Lalonde  1971],  and 
our  semantics  to  constructs  im piemen  table  by  a  single¬ 
pass  compiler  using  the  XPL  System  [ McKeeraan  1970]. 

Quite  obviously,  our  rather  individualistic  view  of  our 
requirements  would  leave  us  unhappy  with  any  language  whose 
definition  and  compiler  we  did  not  control.  We  decided  very 
early  in  Project  SUE  that  is  woula  be  necessary  to  design  and 
build  our  own  [Clark  and  Horning  1971].  The  language  presented 
in  the  next  section  is  the  result  of  our  efforts  to  follow  our 
premises  to  their  natural  conclusions. 

7 . 2  Features  of  the  System  Language 

7.2.1  C0m2ilati0n_St.ruct.ures  The  System  Language  was  designed 
to  facilitate  separate  compilation  of  hierarchically  related 
programs.  A  system  of  programs  consists  of  several  compilation 
blocks^  separated  by  the  symbol  Figure  7. 2.  1-1  is  an 

excerpt  from  a  small  system  of  programs,  whose  structure  is 
diagrammed  in  Figure  7.2. 1-2. 


context  Example; 

type  Alpha  =  { *  A •  to  *Z'); 
type  Names  =  character  ( 30)  ; 
type  Links  =  pointer  to  Node; 
type  Node  = 
record 

Names  (Name)  , 

Links  (Left,  Right,  Father), 

(0  to  10000)  (Count) 

end ; 

type  Path  =  (Start,  Less,  Greater) ; 
type  Scheme  =  (Cartesian,  Polar) ; 
type  Position  = 
record 

case  Scheme  tag  Co_o rdinates ; 

Cartesian:  (-1000  to  1000)  (X,  Y) ; 

Polar:  (0  to  359)  (Theta) , 

(0  to  1000)  (Radius) 

end 

end ; 

data  Main; 

declare 

procedure  accepts  (Names)  returns  (Links)  (Ente 
Look_up) , 

procedure  accepts  (Links)  (Dump), 
procedure  returns  (Names)  (Input), 
powerset  of  Alpha  (Occurs) , 

Links  (Root) , 

(0  to  100000)  (Counter), 
area  10  (Space) ; 

_1_ 


Figure_7i2iJl2j_Exaii!ple_Progr  am 
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program  Wain; 

macro  Decide; 

((Counter  :=  Counter  *  1)  mod  10  =  9) 
end  macro; 
declare 

Alpha  ( I )  , 


Names  (New_name) , 
register  Links  (Work)  ; 

constant  Flag_name  =  *  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ * ; 
Root  : =  Null ; 

Occurs  :=  Empty; 

Counter  :=  0; 
cycle 

Work  :  =  Enter  (New_name  :=  Input)  ; 
assert  WorkuUName  =  New_name; 

....  exit  when  New_na:ne  =  Flag_name; 
if  Decide; 

then:  Dump  (Work) 
end 

end ; 

do  I  :  =  each  Alpha; 

it  I  <=  Occurs; 

then:  Dump  (Look-up  (I  |  | 

*  ') 

end 


end 


I 


Figur  e_7i2i  1_i;i  _ Example_ProgLam 


data  Enter  (New) ; 
declare 

Links  {P)  , 

Path  (X)  ; 

program  Enter; 

P  :=  Root; 

X  :=  Start; 
cycle 

....  exit  when  P  =  Null; 
begin 

open  Pd; 
if  Name  =  New; 

then;  Count  :=  Count  +  1; 
....  return  with  P 

end; 

Q  :=  P; 

if  Name  <  New; 

then:  P  :=  Right; 

X  :=  Less; 
else:  P  :=  Left; 

X  :=  Greater 

end 

end 

end ; 

P  :=  Allocate  (Node,  Space); 

Pd  :=  (New,  Null,  Null,  Q,  1)  ; 

Occurs  :=  Occurs  j  Substr  (New,  1,  1); 
case  Path  tag  X; 

....  Start:  return  with  Root  :=  P; 

....  Less:  return  with  Qd. Right  :=  P; 

. ...  Greater:  return  with  Qd.Left  :=  P 

end 

_1_ 


Figure  7. 2 . 1- 1 jconcl) _ Example  Program 


60 
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Procedures  are  declared  in  their  enclosing  scopes  (e. g. , 
Enter  and  Look_up  in  data  Main).  A  procedure  declaration 
contains  only  the  information  needed  to  compile  (and  type-check) 
calls  on  that  procedure:  the  types  of  its  parameters  and 
returned  values  (if  any),  and  its  name.  Each  procedure  has  a 
data  block  in  which  information  that  is  shared  with  its  local 
(contained)  procedures  (if  any)  occurs:  the  names  of  its 
parameters  and  returned  values,  and  declarations  of  its  local 
procedures  and  all  common  variables,  types,  and  macros.  context 
blocks  are  similar  to  data  blocks,  but  are  restricted  to 
constant  information  (e.g.,  types)  which  is  to  be  shared  by  the 
procedures  of  cooperating  processes;  they  are  the  repository  of 
all  declarations  involving  absolute  machine  locations.  Finally, 
each  procedure  has  a  ptegram  block,  which  contains  its 
executable  code  and  any  purely  local  declarations. 

The  result  of  compiling  a  context  or  data  block  is  a  symbol 
table;  of  a  program  block,  a  loadable  program  module.  Any 
program  block  (even  tor  an  internal  procedure)  may  be  modified 
and  recompiled  without  affecting  any  other  module  in  the  system. 
Modification  of  a  data  block  (which  we  expect  to  be  less 
frequent),  involves  shared  information  and  therefore  requires 
the  recompilation  of  all  affected  blocks--its  program  block,  any 
contained  data  blocks  and  their  program  blocks. 
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The  structure  of  the  System  Language  encourages  the 
development  of  programs  by  conceptual  refinement.  Operations 
which  are  logically  primitive  at  one  level  of  abstraction  are 
defined  in  terms  of  more  basic  operations  at  the  next.  Some 
levels  of  refinement  are  achieved  by  means  of  procedures, 
others,  by  textual  macros  that  are  expanded  at  compile  time  in  a 
fashion  similar  to  the  "Algol  60  copy  rule".  The  form  and 
context  of  macro  calls  and  procedure  calls  (and,  indeed,  of 
array  references)  are  identical.  Thus  a  procedure  may  be 
replaced  by  a  macro  (or  vice  versa)  merely  by  changing  its 
declaration.  E.g.,  in  Figure  7.2.  1-1  Decide  is  declared  as  a 
macro  in  £rograra  Main;  no  other  change  to  the  text  of  £ro<gram 
Main  would  be  required  if  this  were  replaced  by  a  procedure 
declaration  for  Decide. 

7.2.2  Data  Structures  Our  philosophy  of  data  structures  more 
closely  resembles  that  of  Pascal  than  those  of  most  "systems" 
languages.  Data  types  are  characterized  not  only  by  their 
storage  representations  and  the  names  of  their  constants,  but 
also  by  the  valid  operations  (including  assignments)  which  are 
defined  for  them.  The  System  Language  does  not  permit  haphazard 
mixing  of  types.  Although  Less  and  Polar  in  Figure  7. 2.  1-1 
happen  to  be  represented  by  the  same  bit  configuration  in 
storage,  there  is  no  logical  relation  between  them  (or  between 
either  of  them  and  the  constant  1) ,  and  there  is  no  reason  to 
assume  that  it  is  valid  (or  useful)  to  assign  the  value  Polar  to 
a  variable  of  type  Path.  Assignments  such  as  X  :=  Polar  and 
operations  such  as  X  +  1  are  detected  by  the  compiler  as 
violations  of  type  restrictions.  We  expect  such  checking  to 
vastly  reduce  the  number  of  undetected  coding  errors.  (For  the 
rare  case  in  which  such  an  operation  is  desirable,  explicit 
type-conversion  functions  are  available.) 

The  structure  of  the  System/360  provides  two  of  our  basic 
classes  of  data  types.  bit  (n)  specifies  an  integer  arithmetic 
type  with  n  bits  of  precision;  the  default  alignment  is  right- 
justified  within  a  "natural"  storage  quantum  (byte,  halfword, 
word,  doubleword)  and  all  operations  are  as  defined  by  the 
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Systein/360  hardware.  Integer  arithmetic  types  may  be  freely 
mixed  in  all  operations.  character  (n)  specifies  a  string  of  n 
consecutive  characters  (bytes),  to  which  the  Systein/360 
character  operations  (and  concatenation)  may  apply.  Conversion 
between  character  and  integer  types  is  not  automatic. 

Much  of  the  information  with  which  programs  deal  is  not 
numeric  in  nature,  and  any  mapping  of  its  values  into  integers 
is  arbitrary.  The  System  Language  allows  the  programmer  to 
define  a  new  type  merely  by  naming  all  the  distinct  constants 
which  it  is  to  contain,  e.g.,  type  Path  =  (Start,  Less, 
Greater).  Values  of  the  new  type  may  be  assigned,  compared  (the 
ordering  is  that  of  the  defining  list) ,  and  used  for  the  control 
expressions  of  case  and  do._  Built-in  successor  and  predecessor 
functions  operate  on  any  programmer-defined  data  type. 

Any  contiguous  subrange  of  a  basic  type  is  also  a  data 
type,  e.g.,  (Less  to  Greater),  (0  to  359),  ( 1 9  7  C  to  1984). 
Subranges  may  be  used  to  reduce  the  storage  requirements  of 
variables,  but  are  particularly  useful  for  dimensioning  arrays. 

Arrays  may  be  declared  with  any  number  of  dimensions,  each 
associated  with  an  index  type  defining  the  acceptable  values  in 
the  corresponding  subscript  position.  Subscripts  need  not  be 
numeric:  all  of  the  arithmetic,  character,  programm er -def ined , 
and  subrange  data  types  are  valid  index  types,  e.g.,  array 
(Alpha)  of  bit  (32)  allows  the  subscripts  ’A',  'B',  ...,  'Z*. 
The  data  elements  of  an  array  may  be  of  any  type  supported  in 
the  language.  For  efficiency,  all  array  bounds  are  determined 
at  compile  time. 

A  powerset  type  has  as  its  possible  values  the  set  of  all 
subsets  of  values  of  some  index  type,  and  is  partially  ordered 
by  set  containment.  Powerset  values  are  implemented  as  bit 
strings,  and  the  operations  of  intersection,  union,  and 
complementation  are  implemented  by  harware  andt  orA  and 
§^£insiye  or  operations.  In  operations  involving  a  type  and  its 
powerset,  the  element  is  converted  to  a  singleton  set  before  the 
operation.  E.g.,  if  I  is  of  type  Alpha  and  Occurs  is  of  type 
22jf^Lset  of  Alpha,  then  Occurs  |  I  is  the  set  union 
Occurs  U  {  I } ,  and  I  <=  Occurs  is  true  if  I  is  contained  in 
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Occurs. 

Indirection  is  a  key  feature  of  many  operating  system 
tables,  and  we  expect  pointer  values  and  variables  to  be  used 
extensively.  However,  nothing  is  more  dangerous  than  a  pointer 
gone  amok.  Not  only  does  the  undisciplined  use  of  pointers 
tempt  fate,  it  also  invalidates  any  effort  to  do  complete 
compile-time  type  checking.  The  System  Language  therefore  does 
not  contain  a  type  pointer^  Rather,  pointer  to  any  type  is 
another  type.  The  compiler  thus  knows  the  type  which  results 
from  following  (dereferencing)  any  pointer,  and  furthermore,  can 
determine  by  context  when  dereferencing  is  required.  The  built- 
in  Allocate  function,  which  returns  a  pointer,  has  the  type  as  a 
parameter.  Another  danger  is  pointers  that  outlive  the  objects 
they  reference.  Thus  we  have  the  compiler  detect  assignments  of 
pointer  values  to  more  global  (longer- lived)  pointer  variables. 

All  elements  of  an  array  must  be  of  the  same  type.  The 
System  Language  allows  more  general  data  structures  which  do  not 
meet  this  condition.  A  record  type  is  an  ordered  and  named  list 
of  types.  Just  as  we  may  refer  either  to  an  array  or  to  an 
element  of  an  array,  we  may  refer  to  a  record  or  to  a  field  of  a 
record.  Field  selection  is  indicated  by  appending  a  period  and 
the  field  name  to  the  record  name,  e.g.,  Ne w_node. Name  .  Unlike 
array  elements,  fields  may  not  be  selected  by  expressions.  Use 
of  an  unqualified  record  name  indicates  a  tuple  value,  i.e.,  an 
ordered  set  of  values;  the  structure  implied  is  that  of  the 
record  in  storage,  i.e.,  linear,  rather  than  tree-structured.  A 
record  may  have  a  variable  format,  selected  by  a  tag  field  of 
some  index  type  preceding  the  variant  part.  Each  alternative 
list  of  fields  is  labelled  by  one  or  more  constants  of  the  index 
type  indicating  which  values  of  the  tag  variable  cause  that 
format  to  be  selected.  (See  the  declaration  of  type  Position  in 
context  Example.) 
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A  group  type  is  analogous  to  a  record  type,  except  that 
within  a  group  the  default  alignment  is  in  consecutive  bits,  and 
a  storage  type  is  associated  with  the  group  as  a  whole.  E.g., 
type  Csw  = 

group  bit  (64); 

b i t  ( 4 )  (Key,  Unused), 
pointer  to  Ccw  (Command_address) , 
array  (bit  (4)  )  of  bit(1)  (Status), 
bit  (16)  (Count) 

end 

The  attributes  register  and  aligned  m ,  n  may  be  used  to 
overide  the  default  placement  of  values  in  storage. 

Type  declaration  in  the  System  Language  creates  an  entry  in 
the  symbol  table,  but  does  not  imply  run-time  storage 
allocation.  All  variables  must  be  declared  before  their  use. 
Declaration  of  variables  causes  storage  to  be  allocated  on  the 
stack  whenever  the  immediately  enclosing  scope  iiitocedure  or 
begin  block)  is  entered,  and  freed  upon  exit.  The  built-in 
procedures  Allocate  and  Free  provide  for  more  explicit  control 
of  designated  areas  of  storage. 

7.2.3  Con t r ol_Str uct ures  The  selection  of  control  structures 
contained  in  the  System  Language  reflects  the  Project  SUE 
philosophy.  A  rather  parsimonious  set  was  chosen  for 
convenience  and  efficiency,  guided  by  the  requirement  that 
programs  in  the  System  Language  must  clearly  exhibit  their 
control  structure  and  be  amenable  to  logical  correctness 
arguments. 

Assignment  (denoted  by  :=)  is  treated  as  a  binary  operator 
of  low  precedence,  whose  value  is  its  right  operand,  and  whose 
side-effect  is  the  result  of  copying  its  right  operand  into  the 
location  specified  by  its  left  operand.  It  is  the  only  operator 
which  is  currently  permitted  structured  operands  (arrays, 
records,  and  parenthesized  tuples).  A  tuple  is  a  list  of 
expressions  (possibly  involving  assignment)  separated  by  commas. 
Besides  assignment,  tuples  occur  in  parameter  lists,  return 
lists,  and  do  control  lists.  ilost  of  the  operators  of  PL/I  are 
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allowed,  with  their  PL/I  precedences.  The  unary  suffix  operator 
3  is  used  to  dereference  pointers. 

An  expression  followed  by  a  semi-colon  is  an  executable 
statement.  The  expression  (generally  an  assignment  or  procedure 
call)  is  executed  for  side-effect  and  the  value  (if  any) 
discarded.  A  list  of  statements  is  valid  wherever  a  statement 
is  allowed;  becjin  blocks  are  required  only  to  define  the  scope 
of  names.  (All  composite  statements,  such  as  conditionals,  are 
well- bracketed. ) 

The  basic  selection  mechanism  is  provided  by  the  case 
construct,  which  is  analogous  to  an  array  of  alternative  program 
segments:  the  tag  expression  is  evaluated,  and  the  particular 
statement  list  labelled  by  that  value  (or,  if  that  value  does 
not  occur  as  the  label  of  any  of  the  alternatives,  the  list 
labelled  by  else)  is  then  executed.  Boolean  tag  expressions  are 
so  common  that  if  is  permitted  as  an  abbreviation  for  case 
Boolean  tag,,  and  then  as  a  synonym  for  True.  To  preserve  well- 
bracketness,  the  sequence  of  alternatives  for  case  or  if  is 
terminated  by  an  end. 

Two  forms  of  iteration  are  permitted.  cycle  ...  end 
produces  unbounded  repetition  of  the  contained  statements, 
do  ...  end  produces  bounded  repetition,  with  a  sequence  of 
values  for  a  controlled  variable  which  is  determined  upon  entry 
to  the  loop  as  an  increasing  subrange  (specified  by  expression 
to  expression) ,  a  decreasing  subrange  (expression  dow  nto 
expression) ,  all  the  values  in  a  type  Jeach  type) ,  or  a  tuple  of 
e  xpressions. 

The  escape  constructs  are  return  and  exi  t^_  return 

specifies  escape  from  an  enclosing  procedure,  exit*  from  an 
enclosing  compound;  otherwise  they  are 
label  is  specified,  the  escape  is 
enclosing  construct.)  Escapes  may  be 
depend  upon  the  satisfaction  iwhen)_ 
condition.  They  optionally  return 
selections,  escapes  are  a  disciplined  form  of  branching  whose 
effect  on  _  the  flow  of  control  is  apparent,  yet  they  are 
sufficiently  powerful  to  avoid  the  inefficiencies  that  Knuth  and 
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Floyd  complain  are  inherent  in  languages  without  GO  TO 

statements  [  1971 J.  Conditional  escapes  may  be  used  for  early 
termination  of  do  iterations,  and  are  the  normal  way  of 
terminating  a  cycle  iteration.  Examples  of  conditional  exits 
occur  in  both  program  blocks.  A  typical  use  of  return  is 
program  Factorial; 

....  return  when  N  >  0  with  N  *  Factorial  ( M—  1 )  ; 

....  return  with  1 
_  l_ 

The  repeat  construct  is  similar  to  exp t  except  that  it 
causes  a  transfer  to  the  head,  rather  than  the  tail  of  a 
compound ,  e . g . , 

do  I  :=  1  to  N; 

....  repeat  when  X  (I)  =  0; 

y  : =  1  /  x  (i)  ; 

Sum  : =  Sum  +  Y ; 

Square  Square  +  Y  *  Y 

end 

A  procedure  is  invoked  by  the  appearance  of  its  name, 
followed  by  a  parenthesized  list  of  actual  parameters  (if  it  has 
been  declared  with  parameters) .  The  types  of  all  parameters  are 
checked  at  compile  time.  All  parameters  are  evaluated  before 
the  invocation  and  passed  by  value.  However,  the  parameters  may 
have  been  declared  as  pointers  or  as  procedures,  providing  the 
effect  of  call  by  reference  or  call  by  name.  (Similar  remarks 
apply  to  returned  values.)  Values  may  be  assigned  to  the 
returns  list  either  by  the  return  statement  or  by  explicit 
assignment  to  its  elements. 

Many  primitives  of  our  operating  system  (e.g..  Send, 
Receive)  are  included  as  pseudo-procedures  of  the  System 
Language  although  they  compile  into  Supervisor  Call 
instructions.  Finally,  the  full  instruction  set  of  the 
System/360  is  made  accessible  by  the  pseudo- procedure  Inline, 
which  results  in  the  specified  System/360  machine  instruction 
being  compiled  at  that  point  in  the  program. 

One  statement  in  the  System  Language  is  designed  for 
testing  correctness,  rather  than  controlling  the  computer.  At 
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any  point  the  programmer  may  assert  an  expression  which  is 
intended  to  be  true  whenever  the  flow  of  control  reaches  that 

point.  In  ‘•debug”  mode,  the  compiler  will  produce  code  at  that 

* 

point  to  evaluate  and  test  the  expression  (and  cause  an  error 
trap  if  it  fails).  In  “production”  mode,  the  compiler  treats 
assertions  as  information  for  the  reader  (comments). 


7.3  Organization  of  the  System  Language  Compiler 

The  System  Language  compiler  (SUECOM)  [Clark  1971]  is  being 
implemented  using  the  XPL  translator  writing  system  [McKeeman 
1970].  The  mixed-strategy  precedence  (MSP)  syntactic  analyzer 
and  parser  have  been  replaced  by  LALR  techniques,  suggested  by 
DeRemer  [1969]  as  a  special  case  of  Knuth*s  LR(k)  parsing 
algorithm,  and  implemented  by  Lalonde  [1971].  For  space  and 
time  parsing  efficiency,  we  have  restricted  our  grammar  to 
LALR ( 1)  (look-ahead  of  1). 

The  organization  of  a  typical  compiler  (such  as  XCOM) 
produced  by  the  XPL  system  is  sufficiently  different  from  that 
of  SUECOM  to  warrant  a  brief  description  of  both.  One  should 
realize  that  in  both  examples,  there  is  an  implied  forward 
information  flow  (specifying  such  things  as  constant  values, 
identifier  names  and  symbol  table  locations)  which  is  omitted 
from  the  diagrams  for  simplicity. 
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XCOM  accepts  only  card  input  to  the  recognition  phase.  The 
scanner  removes  blanks  and  card  boundaries,  and  supplies  a  token 
string  to  be  parsed  by  the  analysis  routines.  The  synthesis 
phase  of  the  translator  generates  the  machine  operations  which 
implement  the  semantics  associated  with  each  node  of  the  phrase 
structure  tree,  and  the  code  emitters  produce  the  object  program 
in  precise  machine  format.  The  program  listing  is  produced 
directly  from  card  images,  with  messages  inserted  at  the  points 
where  errors  are  detected.  The  compiler  has  one  pass  and  is 
entirely  core  resident. 
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The  spirit  of  the  above  organization  has  been  carried  over 
to  SUECOM;  however,  many  System  Language  features  have  resulted 
in  modification  of  the  scanner  and  emitter.  The  System  Language 
permits  separate  compilation  of  each  compilation  block  in  a 
family  of  programs.  Consequently  the  compiler  must  save  the 
symbol  table  of  any  context  or  data  block,  and  an  ancestral 
symbol  table  must  be  reconstructed  prior  to  any  compilation  in 
order  to  process  programs  in  their  correct  context.  (Because  we 
wish  to  provide  symbolic  debugging  the  symbol  table  of  a  program 
block  is  also  saved.) 

The  modular  compiling  algorithm  on  which  our  compiler  is 
based  requires  the  ability  to  quickly  access  source  text  for  all 
types  of  compilation  units  so  they  may  be  recompiled  if 
necessary.  To  save  space  and  to  eliminate  rescanning  (by  the 
compiler)  of  source  text  for  each  compilation,  it  was  decided  to 
convert  the  source  into  what  we  have  termed  a  token  file^  The 
source  file  is  scanned  as  it  would  have  been  scanned  by  the 
compiler,  and  converted  to  tokens  which  will  represent  the  input 
to  the  parser.  As  well,  this  token  file  contains  all 
information  that  is  required  to  reconstruct  a  source  listing. 
For  example,  reserved  words  are  converted  to  8-bit  tokens  that 
are  indices  into  a  vocabulary  table  and  identifiers  are 
converted  to  a  token,  a  length,  and  a  character  string  that  is 
the  EBCDIC  representation  of  the  identifier. 

In  the  preliminary  tests  it  has  been  found  that  the  space 
needed  to  store  the  token  file  is  about  one-third  of  the  space 
needed  to  save  the  corresponding  card  images.  As  well,  it  is 
known  that  scanning  takes  25-35%  of  the  time  required  for 
compilation.  This  system  takes  scanning  completely  out  of  the 
compilation  stage. 
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rescanning  the  entire  input  deck  each  time  a  change  is  made. 

The  token  file  as  previously  described  is  a  set  of  tokens 
and  textual  information.  However,  paragraphing  significance  may 
be  attached  to  certain  tokens  or  classes  of  tokens  in  the  file. 
A  paragraphing  procedure  has  been  written  to  accept  the  token 
file  as  input  and  produce  a  listing  that  obeys  the  paragraphing 
rules  of  the  SUE  System  Language.  The  program  has  been 
parameterized  so  the  rules  may  be  changed  to  reflect  the  current 
conventions  of  the  Project.  As  well,  the  capability  now  exists 
of  producing  a  uniform  listing  of  all  SUE  coding.  Certain  other 
advantages  are  gained:  upper  and  lower  case  letters  may  be 
combined  to  aid  in  recognition  of  language  features  and  escape 
constructs  may  be  flagged  with  characters  that  are  not  present 
in  the  input  text. 

This  system  of  token  file  preparation,  update,  and  source 
reconstruction  is  a  complete  set  that  allows  flexibility  and 
increased  speed  of  compilation,  in  addition  to  virtual 
independence  from  the  punched  card. 

The  mnemonic  nature  of  the  System  Language,  together  with 
the  high  degree  of  compile-time  type  checking,  has  resulted  in 
identifiers  having  many  uses.  To  remove  potential  syntactic 
ambiguities,  <identifier>  is  a  non-terminal  symbol  which  is  re¬ 
written  as  Cconstant  identified,  <procedure  identified, 
<variable  identified,  <exit  identified,  <index  type 
identified,  Ccompound  type  identified,  or  Cundeclared 

identified.  These  terminal  symbols  are  created  in  the 

identifier  converter  by  the  use  of  the  symbol  table.  In  a 
program  engineering  sense  this  is  undesirable  because  it  causes 
the  backward  information  flow  of  symbol  table  information  (see 
Figure  7.3-2).  We  allow  this  for  the  following  reasons: 

(1)  We  did  not  wish  to  make  artificial  changes  to  the 

syntax  merely  for  the  purpose  of  eliminating 

ambiguities. 

(2)  In  cases  where  the  ambiguities  were  local,  we  refused 
the  inefficiency  of  additional  lookahead  in  the  parser. 

(3)  This  solution  allows  us  to  detect  a  large  number  of 

violations  of  type  restrictions  syntactically. 
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simplifying  the  synthesis  procedure. 

(4)  Since  we  are  committed  to  a  one-pass  compiler,  we 
accept  the  identifier  converter's  dependence  on  the 
processing  of  previous  source. 

The  implementation  of  SUECOPI  is  currently  in  progress.  The 
processing  of  type  definitions  and  variable  declarations  is 
nearly  complete,  the  run-time  organization  is  designed,  code 
templates  for  control  structures  and  procedure  call  and  return 
defined,  and  strategies  for  expression  decoding  have  been 
selected.  The  following  description  concentrates  on  the  novel 
features  of  the  implementation. 

7.4  Scope  Rules  and  Declarations 

7.4.1  The  Symbol  Table  The  symbol  table  is  used  to  manage  all 
identifiers.  The  System  Language  block  structure  has  led  to  the 
adoption  of  a  stack-oriented  structure  with  a  display  stack  for 
scope  marks.  A  new  scope  is  opened  at  the  start  of  any 
compilation  or  internal  scope  block.  The  symbols  declared  in 
that  scope  are  stacked  as  they  are  encountered,  and  are  popped 
when  the  scope  is  exited.  To  increase  look-up  speeds,  a  hash  is 
used  with  a  256-bucket  hash  table  [ KcKeeraan  and  McDaniel  1970], 
Since  the  System  Language  is  being  used  for  the  implementation 
of  a  special-purpose  product,  we  intend  to  defer  a  concentrated 
effort  on  the  selection  of  a  hash  function  until  statistics  are 
gathered  on  the  naming  conventions  used  by  Project  SUE 
programmers. 

7.4.2  The  Type  Stack  The  amount  of  type  information  associated 
with  bit  or  character  types  is  small;  the  amount  associated  with 
records  is  unbounded  (though  finite) .  It  is  prohibitive  to 
store  type  information  in  the  symbol  table;  auxilary  space  is 
required.  Since  the  data  structures  of  XPL  do  not  explicitly 
supply  the  capability  of  variable  formatting,  we  chose  to  use  a 
type  stack  which  is  an  array  of  halfwords.  Each  type  is 
represented  by  a  fixed  header  entry  of  four  halfwords  and  a 
variable  {possibly  empty)  entry. 
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The  compound  types  iP£ocedurex  arrayA  recor dx  groups  are 
recursive.  To  ensure  that  type  entries  in  the  type  stack  are 
disjoint,  a  temporary  stack  is  used .  Variable  portions  of  the 
type  stack  are  built  for  these  types  on  top  of  the  temporary 
stack  and  the  start  of  each  such  entry  is  marked  by  a  display. 
This  allows,  for  example,  an  array  type  to  be  processed  within  a 
record,  leaving  the  partial  entry  for  the  containing  record 
intact  in  the  type  stack. 

7.5  F un-Ti me_Organiza t ion 


7.5.1  Introduction  The  techniques  for  gathering  symbols, 
obeying  rules  of  scope,  and  parsing  data  and  control  structures 
are  independent  of  the  target  machine;  those  for  generating 
machine  addresses,  allocating  variables  and  decoding  expressions 
are  not.  We  feel  that  the  starting  point  in  a  code  generation 
project  must  be  the  design  of  the  run-time  organization.  Lack 
of  foresight  in  planning  linkage  and  addressing  strategies 
results  in  inadequacies  which  often  go  undetected  until  many 
dependent  decisions  have  been  made.  Temporary  fixes  to  such 
problems  are  not  only  unsatisfying,  they  can  breed  further 
problems.  When  deadlines  are  fixed  and  demanding,  re-design  is 
frequently  out  of  the  question. 

We  will  refer  to  the  example  in  Figure  7.5. 1-1  in  our 
discussion  of  the  run-time  organization.  For  convenience,  we 
represent  each  procedure  as  a  single  node,  rather  than 
diagramming  data  and  .program  blocks  separately. 
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7.5.2  Data  Addressability  SUECOM  views  a  procedure  tree  (such 
as  Figure  7.5. 1-1)  statically  when  compiling  the  component 
procedures.  That  is,  when  G  is  being  compiled,  the  state  of  the 
world  is  adequately  described  by  the  label  G,  since  the  tree 
supplies  the  context  by  the  chain  A-C-G.  (If  A  and  C  have  not 
been  compiled,  the  compiler  detects  the  environment  error.) 
However,  a  run-time  description  is  inadequate  if  it  merely 
specifies  procedure  G  as  the  point  of  execution;  we  must  know 
past  history  of  procedure  invocations  as  well. 

The  dynamic  stack  described  in  Randell  and  Russell  [1964] 
is  a  device  for  saving  such  information  at  run-time.  The  return 
address  is  stacked  on  procedure  call,  and  popped  on  procedure 
return.  If  a  procedure  returns  from  a  containing  procedure 
(e.g. ,  K  returns  from  C  in  Figure  7.5. 1-1),  several  entries  must 
be  popped  from  the  dynamic  stack.  Since  the  System/360  has  no 
stack  hardware,  we  implement  it  in  the  save  area  of  the  data 
stack  (to  be  described  below) . 

All  program  blocks  must  be  re-entrant.  As  a  result  fresh 
storage  must  be  obtained  for  all  declarations  in  the  data  and 
program  blocks  on  entry  to  a  procedure,  and  must  be  freed  on 
procedure  exit  on  a  Last-In-First-Out  basis;  we  use  a  stack  to 
manage  this  storage. 

At  compile- time ,  a  procedure  may  reference  variables 
declared  in  any  containing  compilation  block;  at  run-time  the 
storage  for  such  variables  must  be  addressable  to  it.  He  have 
borrowed  the  display  mechanism  of  Randell  and  Russell  [1964]  to 
implement  this  requirement.  To  each  node  in  the  family  tree  we 
assign  a  lexic  level  which  equals  the  length  of  the  chain  from 
that  node  to  the  tree  root.  By  pointing  the  ith  slot  in  the 
display  at  the  storage  local  to  the  lexic  level  i  ancestor,  we 
may  use  the  offsets  from  the  beginning  of  a  storage  block  (which 
are  known  at  compile  time)  to  address  any  variable  in  the 
current  scope. 

He  classify  the  types  of  procedure  calls  into  three 
categories: 

A  downlevel  call  invokes  a  procedure  which  is  declared  in 
the  calling  procedure's  data  block.  For  example,  G  calls  K  in 


74 


Figure  7-5-  1—1. 

An  uplevel  call  invokes  a  procedure  which  is  not  declared 
in  the  calling  procedure's  data  block.  For  example,  G  calls  H 
or  C  in  Figure  7.5. 1-1. 

A  2^r ame tr ic_£rocedure  call  invokes  a  procedure  which  has 
been  passed  in  as  a  parameter.  For  example,  B  passes  D  to  C , 
and  C  calls  the  corresponding  formal  parameter. 

On  each  procedure  linkage,  the  display  must  be  updated  by 
an  operation  which  varies  in  complexity  depending  on  the  nature 
of  the  call  or  return.  Downlevel  calls  require  the  new  base  to 
be  stacked  on  top  of  the  display  (i.e.,  at  the  next  lexic  level) 
and  popped  in  the  return  linkage.  Uplevel  calls  require  the 
saving  of  part  of  the  display  to  be  restored  on  return. 
Parametric  procedure  calls  entail  restoring  the  display  to  its 
value  at  the  time  the  procedure  parameter  was  passed.  Each  of 
these  classes  can  be  distinguished  at  compile  time,  eliminating 
the  need  for  either  the  most  pessimistic  calling  sequence  or  a 
run-time  procedure  to  effect  the  linkage. 

For  efficiency,  we  implement  the  display  in  some  of  the 
general  registers,  and  the  offsets  as  displacements.  However, 
the  System/360  restricts  displacements  to  the  range  0  to  4095, 
placing  an  intolerable  limit  on  the  size  of  a  data  block.  To 
allow  a  data  block  the  freedom  of  larger  storage  areas,  we 
refine  our  definition  of  lexic  level  as  follows: 

(1)  We  assign  one  display  entry  to  each  4K  block  of  storage 
(or  part  thereof)  at  any  node. 

(2)  For  any  node,  we  initialize  the  lexic  level  to  the 
number  of  display  registers  used  in  the  ancestral 
chain.  The  root  lexic  level  is  initialized  to  0. 

This  definition  relieves  the  storage  declaration 
restrictions,  but  could  conceivably  require  more  entries  for  the 
display  than  are  available  in  the  fifteen  general  registers. 
When  this  happens,  we  must  store  part  of  the  display  in  main 
memory,  and  load  these  address  bases  into  a  register  when  they 
are  needed. 
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7.5.3  Core _ Layout  We  precede  our  core  layouts  with  the 

definition  of  our  notation. 

Registers 


AO  #  • • • § 

Ak 
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DO,  •  •  •  , 

Dj 

:  Display 

PROG 

:  Current  procedure  entry  point  address 

RET 

:  Return  address 

D2 

D1 

DO 

RET 

PROG 

AO 


A2 


Figure  7.5. 3-1  Register  Layout 

Accumulator  registers  will  be  allocated  as  required  for 
expression  evaluation  and  address  calculations  on  a  temporary 
basis,  as  well  as  for  variables  of  attribute  register.  Extra 
code  area  addressability  is  obtained  by  first  using  RET,  and 
then  consuming  accumulators.  The  scope  rules  determine  the 
number  of  required  display  registers,  thus  making  the 
availability  of  accumulator  registers  known  at  compile  time. 
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Figure  7? b . 3-2 _ Da ta  Stack  Layout 
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The  following  displacements  will  be  included  in  the  core 
layout  diagrams  and  the  linkage  sequences.  All  are  computable 
at  compile-time: 

dl:  This  is  the  amount  of  storage  consumed  by  the  save 
area,  return  values,  parameters,  local  storage,  and 
temporaries  at  the  time  of  the  call. 
d2 :  This  is  the  offset  from  the  calling  program  save  area 
where  the  called  program  saves  PROG  and  RET. 
d3:  This  is  the  offset  in  the  containing  procedure  of  the 
address  of  the  called  procedure. 

The  data  stack  layout  shows  the  boundary  between  two 
procedures  resulting  from  a  procedure  call  from  level  n  to  level 
a.  The  calling  program  save  area  is  stored  in  the  called 
program  stack  area  for  addressability  reasons.  It  is  situated 
at  the  base  of  the  called  program  stack  area  to  allow  system 
inspection  of  any  process  data  stack  by  following  the  forward 
links.  Doubleword  alignment  ensures  that  field  alignment  within 
a  structured  type  will  be  consistent  among  the  set  of  programs 
which  share  it. 
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Figure  7. 5. 3-3  Program  Area  Layout 


The  program  layout  shows  several  values  which  are  inserted 
by  the  loader.  Local  procedures  have  their  entry  point 
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addresses  stored  in  the  program  area  prefix  of  the  containing 
procedure.  To  allow  for  parametric  procedure  calls,  we  store 
the  lexic  level  in  the  high-order  eight  bits  of  the  fullwords 
containing  these  addresses.  The  constant  DELIA  is  the  total 
amount  of  stack  space  required  by  a  program  and  all  its 
descendants  if  no  uplevel  calls  are  encountered.  On  each 
uplevel  call  we  compare  the  required  space  (DELTA)  plus  the 
space  used  with  the  total  space  (stored  in  the  first  doubleword 
of  the  stack  area)  ,  thus  detecting  possible  stack  overflow 
before  it  occurs.  This  scheme  minimizes  the  number  cf  overflow 
tests,  but  may  kill  a  process  which  could  run  to  completion 
within  the  existing  space.  The  stack  overflow  primitive, 
invoked  by  the  entry  sequence  when  space  is  possibly 
insufficient,  stops  the  process  and  notifies  its  father  of  the 
difficulty. 


7.5.4  Linkage _ to _ N  on_^  P  a  qne  1 1:  i  c _ Procedures  We  make  the 

following  assumptions  on  the  state  of  the  world  at  the  time  of 
procedure  linkage: 

(1)  The  call  is  from  level  n  to  level  m. 

(2)  j  is  the  least  integer  such  that  all  Ai  are  free  for 

i  >  j. 

(3)  The  value  of  dl  is  such  that  Dn  supplies  addressability 

when  registers  and  parameters  are  being  stored.  If 
this  does  not  hold,  we  must  compute  dl  (Dn)  in  a 

temporary  register. 

(4)  dl  is  a  multiple  of  8,  and  thus  the  forward  links  are 
doubleword  aligned. 


Calling  Sequence 

1.  SAVE  REGISTERS. 


ST^  Q, A j,d 1  +  x  (Dn) 

where  Q  =  PROG  if  m>n 
=  Dn  if  m<=n 

=  Di  if  any  procedure  parameters  being  passed 
have  maximum  level  =  i+1,  and  m>n 
and  where  x  is  a  function  of  Q  and  d2  which  forces  PROG  and 
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RET  to  fall  a  predictable  distance  above  dl.  (If  we  were 
to  save  all  registers,  x  would  have  the  value  4.) 

The  actual  register  numbering  has  not  been  bound  in 
this  paper;  however,  the  reader  should  realize  that  the 
allocation  scheme  must  be  such  that,  for  example,  this  STM 
always  saves  PROG. 

_ OBTAIN  PARAMETERS. 

(evaluate  and  place  parameters  in  the  stack 
immediately  above  the  new  save  area) 

3^ _ UPDATE  DISPLAY. 

If  m  =  n,  then  we  must  not  wipe  out  Dn  with  the  value 
of  Dm  until  the  forward  link  has  been  stored.  Thus: 

LR  T, Dn 

LA  Dm ,d 1 ( , Dn) 

If  m-*=n,  we  omit  the  LR  instruction,  and  let  T=Dn. 

4.  _ forward.link^ 

We  must  store  the  new  value  of  Dm  in  the  location 
pointed  at  by  the  old  Dn. 

ST  Dm , 0  ( , T) 

We  also  mark  the  end  of  the  forward  link  chain: 

M VI  0 (Dm) , X  *  FF  * 

5.  _ LOA  D_PR  OG_WITH_ENT  R  Y_POI  NT_  AD  DR  ES  S_j_ 

On  uplevel  calls,  we  must  use  Dm  to  retrieve  PROG  (m- 
1) .  This  gives  us  addressability  to  the  entry  point 
address  stored  in  the  program  area  prefix.  On  downlevel 
calls,  this  is  omitted. 

L  PROG,d2  +  4  (,D  (m-1) ) 

In  any  case,  PROG  now  gives  us  addressability  to  the 
required  address. 

L  PROG ,d3  (, PROG) 

6X _ BRANCH  AND  LINK  TO  CALLED  PROCEDURE. 

On  downlevel  calls  we  by-pass  the  stack  overflow  test: 

BALE  RET, PROG 

On  uplevel  calls,  we  perform  the  test: 

BAL  RET, 4(, PROG) 

7. _ RESTORE  WORLD  ON _ RETURN. 

(retrieve  return  values) 


8  0 


restore  registers: 
8.  RESET  FORWARD  LINK. 


L M  Q ,  A  j  x  (Did) 

MV I  0 ( Dn ) , X  *  FF  * 


Entry  Sequence 


downlevel  ep: 
uplevel  ep: 


test  for  stack  overflow: 


OFFSET 


E  OFFSET  (, FROG) 

L  R  T ,  D  in 

A  T,  DELTA  (,  PROG) 

S  T, STACKLIMIT 
BN  ii  OFFSET  (, PROG) 

SVC  STACKOVERFLOW 

DELTA 

PROCNAME 

CONTAINED  PROCEDURE  ENTRY 
POINTS 

ST  M  RET , PROG  ,  d  2  (  Dm ) 
(establish  further 
addressability  if  needed) 


Return  Sequence  (Return  from  level  i) 

(compute  and  store 
return  values  using 
Di  for  addressability) 

If  RET  has  been  used  for  program  addressability,  we 
must  restore  it: 

L  RET , d  2  ( ,  Di ) 

It  the  RETURN  is  through  several  levels  of  procedure 
calls,  we  must  restore  the  value  of  RET  and  PROG  for  the 
outermost  procedure  being  exited.  In  this  case,  we  emit 
the  single  instruction: 

LM  RET, PROG, d2 (Di) 

If  neither  of  the  above  cases  applies,  we  need  not 
restore  PROG  and  RET. 

To  return,  we  simply  emit: 

BB  RET 

Since  a  procedure  is  often  called  from  more  than  one  place, 
one  would  prefer  to  have  a  single  copy  of  the  linkage  code  in 
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the  entry  sequence,  rather  than  many  copies  in  calling 
sequences.  Our  reasons  for  doing  most  of  the  work  in  the 
calling  sequence  should  be  pointed  out. 

The  primary  reason  is  that  a  procedure  never  knows  from 
what  lexic  level  it  was  called,  and  thus  the  value  of  n  cannot 
be  used  in  compiling  the  procedure.  Thus  efficient  special-case 
linkages  could  not  be  provided.  Since  we  wanted  to  encourage 
the  use  of  procedures,  we  tried  to  make  the  linkage  sequence  as 
efficient  as  possible. 

Sections  2,  5,  and  6  must  appear  in  the  calling  sequence. 
Ml  other  sections  except  for  7  use  Dn,  and  thus  are  placed  in 
the  calling  sequence  as  well.  Moreover,  by  saving  the  registers 
in  the  calling  sequence,  the  accumulators  are  always  free  for 
parameter  evaluation.  Since  we  know  which  registers  have  been 
saved  in  the  calling  sequence,  we  also  restore  them  there. 

The  calling  sequence  must  save  the  old  value  of  PROG  before 
wiping  it  out  with  its  new  value.  When  the  display  needs  to  be 
saved  as  well,  we  prefer  to  save  RET  again  (it  was  already  saved 
in  the  previous  entry  sequence)  rather  than  emitting  two  STMs. 
Moreover,  if  RET  has  been  used  for  extra  program  addressability, 
it  must  always  be  saved  in  the  calling  sequence.  The  entry 
sequence  saves  PROG  as  well  as  RET  to  simplify  section  5  of  the 
calling  sequence,  in  subsequent  uplevel  calls. 


7.5.5  Linkage  to  Parameteric  Procedures  The  calling  sequence 
for  the  standard  procedure  linkage  takes  advantage  of  the 
compile-time  knowledge  of  both  the  calling  and  called  lexic 
levels.  When  the  called  procedure  has  been  passed  as  a 
parameter,  its  lexic  level  is  unknown  at  compile-time. 
Moreover,  it  may  not  even  be  visible  in  the  current  scope, 
requiring  a  possibly  complete  resetting  of  the  display. 
However,  we  do  know  that  at  the  time  the  procedure  was  first 
passed  as  a  parameter,  its  scope  was  defined  in  the  display.  By 
saving  the  required  display  entries,  and  a  pointer  to  them,  as 
well  as  its  lexic  level  (ra) ,  we  can  effect  the  linkage  when  the 
parametric  procedure  is  called. 
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The  above  discussion  motivates  the  following  implementation 
of  a  procedure  parameter.  The  value  that  is  passed  is  a 
Parametric  Procedure  Word  (PPW)  with  the  format: 


where: 


m  1 

e.p.  address 

m2  Idisplay  address  1 

1  1  1 

figure 

7. 5.5-1  Format  of  PPW 

(1)  ml  names  the  register  Dm. 

(2)  e.p.  address  is  the  procedure  entry  point. 

(3)  m2  names  the  register  range  used  by  the  LM  instruction 
to  restore  the  ancestral  display. 

(4)  display  address  is  the  address  in  the  save  area  where 
the  reguired  ancestral  display  has  been  saved. 

We  now  give  the  calling  sequence  for  parametric  procedures. 
Since  we  expect  such  calls  to  be  rare ,  we  do  not  onject  to  the 
extra  overhead. 


U _ 8 A  V  E_R EGIST  ER S._ 

STM  Dn  ,  A  j,  u  1  +x  (Dn) 

We  always  save  the  entire  display. 

2  _ OBTAlN_PAHAMETEHSi 

(evaluate  and  place  parameters  in  the  stack 
immediately  above  the  new  save  area) 

3. _ LOAD_PROG_WITH_OThY_pginT_ACCHESS^ 

Before  wiping  out  PROG  with  the  called  procedure  entry 
address,  we  simultaneously  supply  addressability  to  the 
executed  instructions  and  set  the  return  address. 

We  indicate  basing  of  the  executed  instructions,  and 
the  PPW,  as  comments.  We  further  assume  that  Dk  gives 
addressability  to  the  PPW. 

LA  KET , LA  DN- 4  based  on  PROG 
We  now  load  the  entry  address. 

L  PROG, PPW  based  on  Dk 

4j. _ UPDATE_DISPLAY. 

IC  T 1 , PPW 
S  L  L  T 1  ,  4 
LR  T  2 , D  k 


based  on  Dk 
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update  Dm: 
forward  link: 


5. 


6. 


7. 


update  D  { m— 1 )  ...  DO: 

BRANCH, TO_ CALLED, PROCEDURE. 

We  always  test  for  stack  overflow. 


EX 

T1,LADN 

based 

on 

RET 

EX 

T1 , STDN 

based 

on 

RET 

SRL 

T1 , 4 

EX 

T1,LR 

MVI 

0  (T  1 )  ,  X  *  F F 

• 

IC 

T 1  ,  PPW+4 

based 

on 

T  2 

L 

T2 , PPW  +  4 

based 

on 

T2 

EX 

T  1  , LMDISP 

based 

on 

RET 

B 

4  (, PROG) 

Since  RET  is  set  up,  we 

do 

not  have  to  BAL. 

EXECUTED  INSTRUCTIONS. 

B 

18  (, RET) 

LADN 

LA 

*-*,d1  (,Dn) 

STDN 

ST 

*-*,0{,T2) 

LMDISP 

LM 

*-*,*-*,  0  (T2) 

LR 

LR 

T1 ,*-* 

RESTORE  WORLD  ON  RETURN. 

(retrieve  returns  from 

registers) 

SRL 

PROG ,2  4 

EX 

PROG ,LR  based  on 

restore  registers: 

LM 

Dn,A j, x  (T  1) 

(retrieve  remaining 
return  values) 


8.  RESET  FORWARD  LINK. 


MVI  0(Dn),X*FF* 
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7.6  System  Language  Grammar 

1  <Compilation>  :  :=  data  \’ame>  ;  <Data  Block>  _|_ 

2  |  <Context  Name>  ;  <Context  Block>  _|_ 

3  |  drogram  Name>  ;  <Scope  Blcck>  _|_ 

4  <Data  Name>  ::=  data  <Identifier>  <Parameters>  <Returns> 

5  <Parameters>  (  Cldentifier  List>  ) 

6  |  <Empty> 

7  <Retarns>  returns  (  <Identifier  List>  ) 

8  |  <Euipty> 

9  Cldentifier  List>  ::=  <Identifier> 

10  |  Cldentifier  List>  ,  < rdentif ier> 

11  <Identifier>  : <Compound  Type  Identified 

12  |  Clnaex  Type  Identified 

13  |  CConstant  Identified 

14  |  CProcedure  Identified 

15  |  CVariable  Identified 

16  |  CExit  Identifier> 

17  J  CUndeclared  Identified 

18  <Pata  Block>  <Definition>  ;  <Dat.a  Block> 

19  |  <Empty> 

20  <Definition>  ::=  <Declarat. ion) 

21  |  Clem  pi at e> 

22  <Declaration>  declare  declaration  Item> 

23  |  <I)eclarat ion >  ,  declaration  Item> 

24  declaration  Item>  ::  = 

<Declaration  Type>  (  Cldentifier  Li.st>  ) 


25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 


85 


<Teroplate>  : :=  <Macro  Head>  ;  macro 
J  type  <Identifier>  =  <Type> 

1  constant  <Identifier>  =  <Tuple> 

<Macro  Head>  macro  <Identifier>  <Parameters> 

<Type>  <Declaration  Type> 

1  record  <Field  List>  end 
|  group  <Brief  Type>  ;  <Field  List>  end 

<Declaration  Type>  ::=  <Brief  Type> 

1  area  <Number> 

|  procedure  <Parameter  Type>  <Return  Type> 

J  interrupt  handling  procedure 

<Brief  Type>  ::=  CCorapound  Type  Identifier> 

J  <Index  Type> 

J  pointer  to  <Identifier> 

1  powerset  of  <Index  Type> 

|  array  {  CIndex  List>  )  of  <Brief  Type> 

J  <Attribute>  <Brief  Type> 

<Index  Type>  : :=  <Index  Type  Identif ier> 

1  bit  <  <Number>  ) 

|  character  (  <Number>  ) 

1  (  <Identifier  List>  ) 

|  (  <Constant>  to  <Constant>  ) 

|  {  <Constant>  to  *  ) 

<Constant>  ::=  <Unsigned  Constant> 

J  <Adding  Operator>  <Number> 

<Unsigned  Constant>  ::=  <Number> 

|  <String> 

j  <Constant  Identifier> 
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53 

54 

r>5 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 


<T naex  List>  : <Index  Type> 

|  <Index  List>  ,  CIndex  Type> 

CParaaieter  iype>  :  :=  accepts  (  <Type  List>  ) 
|  <Empty> 

<Return  Type>  ::=  returns  (  <Type  List>  ) 

|  CEmpty> 


<Type  List>  <Declaration  Type> 

|  <Ty pe  List>  ,  < Declaration  r y pe> 

<Field  List>  ::=  <Field  Declaration> 

|  < Variant  Part> 

|  <Field  Declaration>  ,  CField  List> 

<Field  Declaration>  <Type>  (  Cldentifier  List>  ) 

|  <Empty> 

<Variant  Part>  ::=  <Variant  Head>  ;  <Variant  List>  end 

<Variant  Head>  ::=  case  CIndex  Type>  tag  <Identifier> 

CVariant  List>  : else  :  < Field  List> 

|  CVariant  Labels>  CField  List> 

|  CVariant  Labels>  CField  List>  ;  CVariant  List> 

CVariant  Labels>  CLabel> 

|  CVariant  Labels>  CLabel> 

CLabel>  : : =  then  : 

|  cConstant>  : 

|  <Constant>  to  CCo'nstant>  : 

CAttritute>  register 

|  aligned 

|  aligned  CNumber>  ,  CNumber> 


87 


79  <Context  Name)  ::=  context  <Identifier> 

80  <Context  Block>  ::=  <Context  Declaration> 

81  |  <Context  Block>  ;  <Context  Declaration) 

82  <Context  Declaration>  : :=  <Teraplate> 

83  |  absolute  (  <Nuraber>  )  <Declaration  Type>  <Identifier> 

84  <Program  Name)  : :=  program  <Procedure  Identifier> 

85  <Scope  Block>  ::=  Executable  Statement  List> 

86  |  <Definition>  ;  <Scope  Block> 

87  |  <0pen  Statement>  ;  <Scope  Block> 

88  <0pen  Statement>  : :=  open  <Storage  Reference) 

89  Executable  Statement  List>  ::=  Executable  Statement> 

90  |  <Executable  Statement  List>  ;  <Executable  Statement> 

91  Executable  Statement>  ::  = 

<Escape>  <Label  Part>  <Condition>  <With  Part> 

92  |  return  <From  Part>  <Condition>  <With  Part) 

93  |  <Selector>  ;  <Alter natives)  end 

94  |  <Compound> 

95  |  <Tuple  Element) 

96  |  assert  CTuple  Element) 

97  1  <Empty> 

j 

98  <Escape>  : :=  exit 

99  |  repeat 

100  <Label  Part)  ::=  <  Exit  Identifier)  ) 

101  |  Empty) 

102  <Condition)  ::=  unless  Expression) 

103  j  when  Expression) 

104  |  Empty) 
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10b  CKith  Eart>  ::=  with  <Tuple> 

106  |  <Empty> 

107  CFrom  Part>  trom  Procedure  Identifier> 

108  j  <Empty> 

109  CSelector>  ::=  if  CExpression> 

110  |  case  CIndex  Type>  tag  CExpression> 

111  Alter nat i ves>  else  :  Executable  Statement  List> 

112  |  Alternative  Labels>  CExecutable  Statement  List> 

113  |  Alternative  Labels>  <Executable  Statement  List> 

<Al ternat ives> 

114  Alternative  Labels>  ::=  <Label> 

115  |  Alternative  Labels>  <Label> 

116  <Compound>  ::=  begin  <Scope  Biock>  end 

117  |  cycle  Executable  Statement  List>  end 

118  |  <Do  Head>  ;  <Executable  Statement  List>  end 

119  |  Exit  Label>  <Compound>  <  <Exit  Identifier>  > 

120  <Do  Head >  :  :  = 

do  CVariable  Identifier>  :=  <Iteration  Control> 

121  CIteration  Control>  ::=  <Tuple> 

122  |  <Expression>  to  CExpression> 

123  |  < Express ion>  downto  CExpression> 

124  |  each  CIndex  Type> 

12b  CExit  Label>  ::=  <  <Identifier>  > 

126  <Tuple>  ::=  CTupie  Element > 

127  |  duple  Element>  ,  <Tuple> 

128  CTupie  Element>  CExpression> 

129  |  CStoraye  Reference>  :=  CTupie  Element> 


130 

131 

132 

133 

134 

135 

136 

137 

138 

1  39 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

151 

150 

152 

153 

154 

155 
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<Expression>  : :=  <Logical  Term> 

|  <Expression>  <Or  Operator>  <Logical  Term> 

<Logical  Term>  ::=  <Logical  Factor> 

|  <Logical  Term>  S  <Logical  Factor> 

<Logical  Factor>  : :=  <String  Expression> 

1  <Logical  Factor>  <Relational  Operator> 

<String  Expression> 

<String  Expression>  ::=  <Numeric  Expression> 

1  <String  Expression>  | |  Numeric  Expression> 

<Numeric  Expression>  : :=  <Numeric  Term> 

j  <Numeric  Expression>  <Adding  Operator>  <Numeric  Term> 

<Numeric  Term>  ::=  <Numeric  Factor> 

|  -»  <Numeric  Factor> 

|  <Adding  Operator>  <Numeric  Factor> 
j  <Numeric  Term>  <Multiplying  Operator> 

<Numeric  Factor> 

<Numeric  Factor>  ::=  <Storage  Reference> 

J  CUnsigned  Constant> 
j  (  <Tuple>  ) 

<Storage  Reference>  <Variable  Identified 

|  <Procedure  Identifier> 

J  <Storage  Reference>  a) 

|  <Storage  Reference>  (  <Tuple>  ) 

J  <Storage  Reference>  .  <Identifier> 

|  typed  <Brief  Type>  (  <Tuple>  ) 

|  exits  with  (  <Type  List>  )  ;  <Compound> 

<Or  Operator>  ::=  j 
1  xor 


9  0 

166 

157 

1  68 

1  59 

160 

161 

162 

163 

164 

165 

1  66 


Relational  Opera tor>  : 


I  > 

I  <  = 
I  >  = 


<Addiny  Operator>  ::=  + 


< Multiplying  Operator> 


I  / 

|  aiod~ 
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